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CHAPTER  1 
INTRODUCTION 


The  Ad?  implementation  described  above  was  tested  according  to  the  Ada  Validation  Procedures 
[Pro90]  against  the  Ada  Standard  [Ada83]  using  the  current  Ada  Compiler  Validation  Capability 
(ACVC).  This  Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada 
implementation.  For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro90].  A 
detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User’s  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada  Certification  Body  may  make 
full  and  free  public  disclosure  of  this  report.  In  the  United  States,  this  is  provided  in  accordance  with 
the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the 
computers,  operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not  represent  or  warrant  that 
all  statements  set  forth  in  this  report  are  accurate  and  complete,  or  that  the  subject  implementation 
has  no  nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield 
VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be  directed  to  the  AVF  which 
performed  this  validation  or  »o: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria 
VA  22311 


1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987 
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[Pro90]  Ada  Compiler  Validation  Procedures. 

Version  2.1,  Ada  Joint  Program  Office,  August  1990. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide. 

21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC  contains  a 
collection  of  test  programs  structured  into  six  test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of 
a  test  name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class 
B  and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a  PASSED,  FAILED,  or 
NOT  APPLICABLE  message  indicating  the  result  when  they  are  executed.  Three  Ada  library  units, 
the  packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used  for  this  purpose. 
The  package  REPORT  also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective.  The  package 
SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada  Standard.  The  procedure  CHECK_FDLE 
is  used  to  check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the 
Ada  Standard.  The  operation  of  REPORT  and  CHECK_F1LE  is  checked  by  a  set  of  executable  tests. 
If  these  units  are  not  operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B  tests  are  not  executable. 
Each  test  in  this  class  is  compiled  and  the  resulting  compilation  listing  is  examined  to  verify  that  all 
violations  of  the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada  code  which 
must  not  be  flagged  illegal  by  the  compiler.  This  behaviour  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of  the  Ada  Standard 
involving  multiple,  separately  compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by  implementation-specific 
values  -  for  example,  the  largest  integer.  A  list  of  the  values  used  for  this  implementation  is 
provided  in  Appendix  A.  In  addition  to  these  anticipated  test  modifications,  additional  changes  may 
be  required  to  remove  unforeseen  conflicts  between  the  tests  and  implementation-dependent 
characteristics.  The  modifications  required  for  this  implementation  are  described  in  section  2.3. 
For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF.  This  customization 
consists  of  making  the  modifications  described  in  the  preceding  paragraph,  removing  withdrawn  tests 
(see  scruon  2.1)  and,  possibly  some  inapplicable  tests  (see  Section  3.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the  customized  test  suite 
according  to  the  Ada  Standard. 
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Ada  Compiler 

Ada  Compiler 
Validation 
Capability  (ACVC) 

Ada  Implementation 

Ada  Validation  Facility 
(AVF) 

Ada  Validation 
Organization  (AVO) 

Compliance  of  an  Ada 
Implementation 

Computer  System 


Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer  System 


Inapplicable  test 


Validation  Summary  Report 


The  software  and  any  needed  hardware  that  have  to  be  added  to  a 
given  host  and  target  computer  system  to  allow  transformation  of 
Ada  programs  into  executable  form  and  execution  thereof. 

The  means  for  testing  compliance  of  Ada  implementations,  consisting 
of  the  test  suite,  the  support  programs,  the  ACVC  user’s  guide  and 
the  template  for  the  validation  summary  report. 

An  Ada  compiler  with  its  host  computer  system  and  its  target 
computer  system 

The  part  of  the  certification  body  which  carries  out  the  procedures 
required  to  establish  the  compliance  of  an  Ada  implementation. 

The  part  of  the  certification  body  that  provides  technical  guidance  for 
operations  of  the  Ada  Certification  system. 

The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or  part  of  a 
program  and  also  for  all  or  part  of  the  data  necessary  for  the 
execution  of  the  program;  executes  user-written  or  user-designated 
programs;  performs  user-designated  data  manipulation,  including 
arithmetic  operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A  computer 
system  may  be  a  stand-alone  unit  or  may  consist  of  several  inter¬ 
connected  units. 

Fulfilment  by  a  product,  process  or  service  of  all  requirements 
specified. 

An  individual  or  corporate  entity  who  enters  into  an  agreement  with 
an  AVF  which  specifies  the  terms  and  conditions  for  AVF  services 
(of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity  is 
realized  or  attainable  on  the  Ada  implementation  for  which 
validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed  into 
executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 
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Operating  System 


Target  Computer 
System 


Software  that  controls  the  execution  of  programs  and  that  provides 
services  such  as  resource  allocation,  scheduling,  input/outpu;  "ontrol, 
and  data  management.  Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware  implementations  are 
possible. 

A  computer  system  where  the  executable  form  of  Ada  programs  are 
executed. 


Validated  Ada  Compiler 

Validated  Ada 
Implementation 

Validation 

Withdrawn  test 


The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully  either 
by  AVF  testing  or  by  registration  [Pro90]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to  the 
Ada  programming  language  and  of  issuing  a  certificate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity  testing.  A 
test  may  be  incorrect  because  it  has  an  invalid  test  objective,  fails  to 
meet  its  test  objective,  or  contains  erroneous  or  illegal  use  of  the 
Ada  programming  language. 
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CHAPTER  2 


IMPLEMENTATION  DEPENDENCIES 
2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for  this  list  of  withdrawn  tests  is 
90-10-12. 


E28005C 

B28006C 

C34006D 

B41308B 

C43004A 

C45114A 

C45346A 

C45612B 

C45651A 

C46022A 

B49008A 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

B85001L 

C83026A 

C83041A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE240SA 

CE3111C 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 


A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant  for  a  given  Ada 
implementation.  The  inapplicability  criteria  for  some  tests  are  explained  in  documents  issued  by  ISO 
and  the  AJPO  known  as  Ada  Issues  and  commonly  referenced  in  the  format  Al-dddd.  For  this 
implementation,  the  following  tests  were  inapplicable  for  the  reasons  indicated;  references  to  Ada 
Issues  are  included  as  appropriate. 


The  following  285  tests  have  floating-point  type  declarations  requiring  more  digits  than 
SYSTEM.MAX_DIGITS: 


C24113F..Y  (20  tests) 
C35706F..Y  (20  tests) 
C35708F..Y  (20  tests) 
C45241F..  Y  (20  tots) 
C45421F..Y  (20  tests) 
C45524F..Z  (21  tests) 
C45641F..Y  (20  tests) 


C35705F..Y  (20  tests) 
C35707F..Y  (20  tests) 
C35802F..Z  (21  tests) 
C45321F..Y  (20  tests) 
C45521F..Z  (21  tests) 
C45621F..Z  (21  tests) 
C46012F..Z  (21  tests) 
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The  following  21  tests  check  for  the  predefined  type  SHORTJNTEGER: 


C35404B 

B36105C 

C45231B 

C45304B 

C45411B 

C45412B 

C45502B 

C45503B 

C45504B 

C45504E 

C45611B 

C45613B 

C45614B 

C45631B 

C45632B 

B52004E 

C55B07B 

B55B09D 

B86001V 

C86006D 

CD7101E 

C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined  integer  type  with  a 
lunne  other  than  INTEGER,  LONGJNTEGER,  or  SHORTJNTEGER. 

C35702A,  C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined  type 
SHORTJFLOAT. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a  name  other  than  FLOAT, 
LONGJFLOAT,  or  SHORT_FLOAT. 

C45423A,  C45523A  and  C45622A  check  that  if  MACHINE_OVERFLOWS  is  TRUE  and  the  results 
of  various  floating-point  operations  lie  outside  the  range  of  the  base  type,  then  the  proper  exception 
is  raised;  for  this  implementation,  MACHINE_OVERFLOWS  is  FALSE. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for  types  that  require  a 
S Y STEM.M AX_M ANTISS A  of  47  or  greater;  for  this  implementation,  MAX_MANTISSA  is  less 
than  47. 


CS6001F  recompiles  package  SYSTEM,  making  package  TEXT_IO,  and  hence  package  REPORT, 
obsolete.  For  this  implementation,  the  package  TEXT  JO  is  dependent  upon  package  SYSTEM. 

BX6001Y  checks  for  a  predefined  fixed-point  type  other  than  DURATION. 

C96005B  checks  for  values  of  type  DURATION’BASE  that  are  outside  the  range  of  DURATION. 
There  are  no  such  values  for  this  implementation. 

CD1009C  uses  a  representation  clause  specifying  a  non-defauit  size  for  a  floating-point  type. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  representation  clauses  specifying 
non-default  sizes  for  access  types. 

The  following  263  tests  check  for  sequential,  text,  and  direct  access  files: 


CE2102A..C  (3) 
CE2103C..D  (2) 
CE2107A..H  (8) 
CE2110A..D  (4) 
CE2201A..C  (3) 
CE2204A..D  (4) 
CE2401A..C  (3) 


CE2102G..H  (2) 
CE2104A..D  (4) 
CE2107L 
CE2111A..I  (9) 
EE2201D..E  (2) 
CE2205A 
EE240LD 


CE2102K 
CE2105A..B  (2) 
CE2108A..H  (8) 
CE2115A..B  (2) 
CE2201F..N  (9) 
CE2206A 
CE2401E..F  (2) 


CE2102N..Y  (12) 
CE2106A..B  (2) 
CE2109A..C  (3) 
CE2120A..B  (2) 
CE2203A 
CE2208B 
EE2401G 
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CE2401H..L  (5) 

CE2403A 

CE2404A..B  (2) 

CE2405B 

CE2406A 

CE2407A..B  (2) 

CE2408A..B  (2) 

CE2409A..B 

(2) 

CE2410A..B  (2) 

CE2411A 

CE3102A..C  (3) 

CE3102F..H 

(3) 

CE3102J..K  (2) 

CE3103A 

CE3104A..C  (3) 

CE3106A..B 

(2) 

CE3107B 

CE3108A..B  (2) 

CE3109A 

CE3110A 

CE3111A..B  (2) 

CE3111D..E  (2) 

CE3112A..D  (4) 

CE3114A..B 

(2) 

CE3115A 

CE3116A 

CE3119A  • 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C..D 

(2). 

CE3403A..C  (3) 

CE3403E..F  (2) 

CE3404B..D  (3) 

CE3405A 

EE3405B 

CE3405C..D  (2) 

CE3406A..D  (4) 

CE3407A..C 

(3) 

CE3408A..C  (3) 

CE3409A 

CE3409C..E  (3) 

EE3409F 

CE3410A 

CE3410C..E  (3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A 

CE3413C 

CE3414A 

CE3602A..D  (4) 

CE3603A 

CE3604A..B  (2) 

CE3605A..E  (5) 

CE3606A..B  (2) 

CE3704A..F 

(6) 

CE3704M..O  (3) 

CE3705A..E  (5) 

CE3706D 

CE3706F..G 

(2) 

CE3804A..P  (16) 

CE3805A..B  (2) 

CE3806A..B  (2) 

CE3806D..E 

(2) 

CE3806H 

CE3904A..B  (2) 

CE3905A..C  (3) 

CE3905L 

CE3906A..C  (3) 

CE3906E..F  (2) 

CE3413B  checks  operations  on  text  files;  this  implementation  does  not  support  external  files.  (See 
section  2.3). 

CE3806G  assumes  that  implementations  not  supporting  text  files  wii*  raise  USE_ERROR  if 
TEXT_IO.CREATE  is  called;  for  this  implementation  NAME_ERROR  is  raised  if  a  non-null  file 
name  is  specified.  (See  section  2.3). 

2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  14  tests. 


The  following  test  was  split  because  syntax  errors  at  one  point  resulted  in  the  compiler  not  detecting 
other  errors  in  the  test: 

By7301E 

C45524A..E  (5  tests)  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  These  tests 
expect  that  a  repeated  division  will  result  in  zero;  but  the  Ada  standard  only  requires  that  the  result 
lie  in  the  smallest  safe  interval.  Thus,  the  tests  were  modified  to  check  that  the  result  was  within  the 
.smallest  safe  interval  by  adding  the  following  code  after  line  138;  the  modified  tests  were  passed: 


ELSIF  VAL  <=  F’SAFE_SMALL  THEN  COMMENT  ("UNDERFLOW  IS  GRADUAL"); 

C64103A  and  C95084A  were  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO. 
Because  this  implementation’s  actual  values  for  LONG_FLOAT’SAFE_LARGE  and 
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SHORT_FLOAT’LAST  lie  within  one  (SHORT _FLOAT)  model  interval  of  each  other,  the  tests’ 
floating-point  applicability  check  may  evaluate  to  TRUE  and  yet  the  subsequent  expected  exception 
need  not  be  raised.  The  AVO  ruled  that  the  implementation's  behaviour  should  be  graded  passed 
because  the  implementation  passed  the  integer  and  fixed-point  checks.  The  following 
REPORT.FAILED  messages  were  produced  after  the  type  conversions  at  line  198  in  C64103A  and 
lines  101  and  250  in  C95084A  failed  to  raise  exceptions: 

C64103A:  "EXCEPTION  NOT  RAISED  AFTER  CALL  -P2  (B)” 

C95084A  "EXCEPTION  NOT  RAISED  BEFORE  CALL  -  T2  (A)" 

"EXCEPTION  NOT  RAISED  AFTER  CALL  -  T5  (B)" 

C64201C,  C99005A  and  A98002A  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO. 
These  tests  respectively  contain  12, 12  and  17  tasks;  given  the  implementation’s  default  amount  of 
storage  allocated  to  a  task,  this  number  of  tasks  causes  STORAGE_ERROR  to  be  raised.  These 
tests  were  modified  to  include  length  clauses  that  specified  IK  bytes  for  the  task  storage  size  (for  tests 
C99005A  and  A98002A,  this  required  that  the  single  tasks  be  re-written  as  task  types);  the  modified 
tests  were  passed. 

CE3413B  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the  AVO.  This  test 
includes  the  expression  "COUNT’LAST  >  150000",  which  raises  CONSTRAINT_ERROR  on  the 
implicit  conversion  of  the  integer  literal  to  type  COUNT  since  COUNT’LAST  =  32,767;  there  is  no 
handler  for  this  exception,  so  test  execution  is  terminated.  The  AVO  ruled  that  this  behaviour  was 
acceptable;  the  AVO  ruled  that  the  test  be  graded  inapplicable  because  it  checks  certain  file 
operations  and  this  implementation  does  not  support  external  files. 

CE3806G  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the  AVO.  This  test  is 
inapplicable  to  implementations  that  do  not  support  external  files.  However,  the  test  incorrectly 
continues  execution  after  handling  NAMEJ2RROR  at  line  42  (and  calling 
REPORT.NOT_APPLICABLE),  and  the  subsequent  attempt  to  create  a  file  results  in  the  test 
aborting  with  an  unhandled  NAJME_ERROR  exception. 

CE3901A  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  This  test  expects  that 
implementations  that  do  not  support  external  files  will  raise  USEJERROR  on  the  attempt  to  create 
a  file  at  line  52;  this  implementation  raises  NAME_ERROR,  as  allowed  by  AI-00332.  The  test  was 
modified  by  inserting  ’|  NAME_ERROR’  into  the  exception  choice  at  line  52,  and  the  modified  test 
was  passed. 
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CHAPTER  3 

PROCESSING  INFORMATION 
3.1  TESTING  ENVIRONMENT 

The  host  and  target  computers  systems  were  connected  via  a  standard  RS232  link.  Other  details 
concerning  the  Ada  implementation  tested  in  this  validation  effort  is  described  adequately  by  the 
information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada  implementation  system,  see: 

Tim  Magness 
SD*Scicon  UK  Ltd 
Pembroke  House 
Pembroke  Broadway 
Camberley 
Surrey 
GUIS  3XD 

For  a  point  of  contact  for  sales  information  about  this  Ada  implementation  system,  see: 

Colin  Foster 
SD-Scicon  UK  Ltd 
Pembroke  House 
Pembroke  Broadway 
Camberley 
Surrey 
GU15  3XD 


Testing  of  this  Ada  implementation  was  conducted  at  the  customer’s  site  by  a  validation  team  from 
the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of  the  customized  test 
suite  in  accordance  with  the  Ada  Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable:  otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained  that  conforms  to  the  Ada 
Programming  Language  Standard. 

a)  Total  Number  of  Applicable  Tests  3486 
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b)  Total  Number  of  Withdrawn  Tests 

c)  Processed  Inapplicable  Tests 

d)  Non-Processed  I/O  Tests 

e)  Non*Processed  Floating-Point  Precision  Tests 

f)  Total  Number  of  Inapplicable  Tests 

g)  Total  Number  of  Tests  for  A CVC  1.11 

When  this  compiler  was  tested,  the  tests  listed  in  section  2.1 
errors. 

3.3  TEST  EXECUTION 

Version  1.11  of  the  ACVC  comprises  4170  tests.  When  this  compiler  was  tested,  the  tests  listed  in 
section  2.1  had  been  withdrawn  because  of  test  errors.  The  AVF  determined  that  603  tests  were 
inapplicable  to  this  implementation.  All  inapplicable  tests  were  processed  during  validation  testing. 
In  addition,  the  modified  tests  mentioned  in  section  2.3  were  also  processed. 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was  taken  on-site  by  the 
validation  team  for  processing.  The  contents  of  the  magnetic  tape  were  loaded  onto  a  VAX  8600  and 
were  transferred  via  DECnet  to  the  host  computer  system. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests  was  processed  by  the  Ada 
implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as  appropriate.  The  executable 
images  were  transferred  to  the  target  computer  system  by  the  communications  link  described  above, 
and  run.  The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and  reviewed  by  the 
validation  team.  See  Appendix  B  for  a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The  op  ions  invoked  explicitly  for  validation 
testing  during  this  test  were: 

/LIST  used  for  tests  requiring  compilation  listings 

/DEV=DAY_0  in-house  compiler  option  to  remove  extraneous  listing  information  eg  dates 

and  headers. 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived 
at  the  AVF.  The  listings  examined  on-site  by  the  validation  team  were  also  archived. 


81 

603 

0 

0 

603  (c+d+e) 

4170  (a+b+f) 

had  been  withdrawn  because  of  test 
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APPENDIX  A 
MACRO  PARAMETERS 

This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The  meaning  and 
purpose  of  these  parameters  are  explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  valued  that  are  defined  in  terms  of  the  maximum  input-line  length, 
which  is  the  value  for  $MAX_IN-LEN--also  listed  here.  These  values  are  expressed  here  as  Ada 
string  aggregates,  where  "V"  represents  the  maximum  input-line  length. 


Macro  Parameter 

$MAX_IN_LEN 

$BIG_ID1 

$BIG_ID2 

$BIG_ID3 

$BIG_ID4 

$BIG_INT_LIT 

$BIG_REAL_LIT 

$BIG_STRING1 

$BIG_STRING2 

SBLANKS 

$MAX_LEN_INT_BASED_LITERAL 

$MAX_LEN_REAL_BASED_LITERAL 

$MAX_STRING_LITERAL 


Macro  Value 
255 

(1..V-1  =>  ’A’,  V  ->  T) 

(1..V-1  =  >  ’A’,  V  =>  ’2’) 

(1..V/2  =>  ’A’)  &  ’3’  &  (1..V-1-V/2  =>  ’A’) 
(1..V/2  =  >  ’A’)  &  ’4’  &  (1..V-1-V/2  =>  ’A’) 
(1..V-3  =>  ’O’)  &  "298" 

(1..V-5  =>  ’O’)  &  "690.0" 

””  &  (1..V/2  =>  ’A’)  & 

””  &  (1..V-1-V/2  =>  ’A’)  &  T  & 

(1..V-20  =>  ”) 

"2:"  &  (1..V-5  =>  ’O’)  &  "11:” 

"16:"  &  (1..V-7  =>  ’O’)  &  "F.E:" 

’"’  &  (1..V-2  =>  ’A’)  &  ’"’ 
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MACRO  PARAMETERS 


The  following  table  lists  all  of  the  other  macro  parameters  and  their  respective  values. 
Macro  Parameter  Macro  Value 


$ACC_SIZE 

SALIGNMENT 

$COUNT_LAST 

$DEFAULT_MEM_SIZE 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRY_ADDRESS 

$ENTRY_ADDRESS1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$FILE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

$FORM_STRING 

$FORM_STRING2 

$GREATER_THAN_DURATION 

$GREATER_THAN_DURATION_BASE 

$GREATER_THAN_FLOAT_BASE_LAS 
SGREATER  THAN  FLOAT  SAFE  LAF 


16 

1 

32767 

131072 

16 

MIL_STD_1750A 
2.0*  *(-31) 

SYSTEM.TO_ADDRESS(32765) 

SYSTEM.TO_ADDRESS(32760) 

SYSTEM.TO_ADDRESS(32755) 

255 

9  9 

NO_SUCH_TYPE 

NO_SUCH_TYPE 

nn 

"CANNOT_RESTRICT_HLE_CAPACITY" 

75000.0 

LAST 

131073.0 

r  3.40283E+38 

GE  1.8E+38 
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$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE 


$HIGH_PRIORITY 

$ILLEGAL_EXTERNAL_FILE_NAME1 

$ILLEGAL_EXTERNAL_FILE_NAME2 

$INAPPROPRIATE_LINE_LENGTH 

SINAPPROPRI  ATE_P  AG  E_LEN  GTH 

$INCLUDE_PRAGMA1 

$INCLUDE_PRAGMA2 

$INTEGER_FIRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1 

$INTERFACE_LANGUAGE 

$LESS_THAN_DURATION 

$LESS_THAN_DURATION_BASE_FIRST 

$LINE_TERMINATOR 

$LOW_PRIORITY 

$MACHINE_CODE_STATEMENT 

$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

SMIN  INT 


"NO_SUCH_TYPEM 

15 

ILLEGAL_EXTERNAL_FILE_NAME1 

ILLEGAL_EXTERNAL_FILE_NAME2 

-1 

-1 

PRAGMA  INCLUDE  ("A28006D1.TST") 
PRAGMA  INCLUDE  ("B28006Dl.TSr) 
-32768 

32767 

32768 

ASSEMBLER 

-75000.0 

-131073.0 
*  » 

0 

OPERANDLESS_INST’(OPCOPE= >NOP); 
OPERANDLESSJNST 
31 
9 

2147483647 

2147483648 

-2147483648 
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SNAME 

$NAME_LIST 

$NAME_SPECIFICATION  1 

$NAME_SPECIFICATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINITION 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

STICK 

$VARIABLE_ADDRESS 

$VARIABLE_ADDRESS1 

$VARIABLE_ADDRESS2 

$YOUR_PRAGMA 


N  0_SUCH_TYPE_AVAILABLE 

MIL_STD_1750A 

NO_SUCHNAME 

NO_SUCH_NAME 

N  0_SU  CH_NAME 

16#FFFFFFFE# 

131072 

16 

MIL_STD_1750A 
>  » 

RECORD  OP  CODE:  OPERANDLESS  OP;  END 
RECORD; 

OPERANDLESSJNST 

16 

4096 

0.0001 

SYSTEM.TO_ADDRESS  (30000) 
SYSTEM.TO_ADDRESS  (20000) 
SYSTEM.TO_ADDRESS  (10000) 
EXPORT_OBJECT 
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APPENDIX  B 

COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  compiler 
documentation  and  not  to  this  report. 


Validation  Summary  Report 


AVF_VSRJW502/72 


SO-Sdcoa  UK  Limited 


Appendix  B  -  Page  1  of  2 


XD  Ada  MIL-STD-175flA  V1.2 


XDADA 


XDADA 


Invokes  the  XD  Ada  compiler  to  compile  one  or  more  source  files. 


Format  XDADA  file-spec[,...] 

Command  Qualifiers 
/LIBRARY  -  directory-spec 

Positional  Qualifiers 
/[N01ANALYSIS_DATA[  -  flle-spsc] 
/(NO)CHECK 
/(NOjCOPY.SOURCE 
/(NOjDEBUG|  -  (option), ...DJ 
/(NO}DIAGNOSTICS[  -  fite-specl 
/tNO)ERRORJJMIT(«n) 
/[NOJLlSTt  -  file-spec) 
/(NO]LOAD(-  option) 
/(NO]MACHINE_CODE(  -  option) 
/)NO)NOTE_SOURCE 
/(NOIOPTIMIZE)- option) 
/)NO)PREOEFINEDJJNIT 
/(NO)SHOW(-  option) 
/(NO]SYNTAX_ONLY 
/(NOIWARNINGSJ-  (option),. ..D) 


Prompt 

_File: 


Command  Parameters 

ff/a-spec 

Specifies  one  or  more  XD  Ada  source  files  to  be  compiled.  If  you  do 
not  specify  a  file  type,  the  compiler  uses  the  default  file  type  of  .ADA. 
No  wildcard  characters  are  allowed  in  the  file  specifications. 


Dafaults 

/LIBRARY  *  XDADASLIB 
Dafaults 

/NOANALYSIS_DATA 
See  text. 
/COPY.SOURCE 
/DEBUG -ALL 
/NODIAGNOSTICS 
/ERRORJJMIT  -30 
/NOLIST 

/LOAD- REPUCE 
/NOMACHINE_CODE 
/NOTE_SOURCE 
See  text. 

/NOPREDEFINEDJJNIT 
/SHOW -PORTABILITY 
/NOSYNTAX_ONLY 
See  text. 


/ 


XDADA 


If  you  specify  more  than  one  input  file,  you  must  separate  adjacent  file 
specifications  with  a  comma  (, ).'  You  cannot  use  a  plus  sign  (  +  )  to 
separate  file  specifications. 


Description 

The  XDADA  command  is  one  of  four  commands  used  to  compile  com¬ 
pilation  units.  The  other  three  are  the  XDACS  COMPILE,  RECOMPILE 
and  LOAD  commands. 

The  XDADA  command  can  be  used  at  any  time  to  compile  one  or 
more  source  files  (.ADA).  Source  files  are  compiled  in  the  order  they 
appear  on  the  command  line.  If  a  source  file  contains  more  than  one 
compilation  unit,  they  are  compiled  in  the  order  they  appear  in  the 
source  file. 

The  XDADA  command  compiles  units  in  the  context  of  the  current 
program  library.  Whenever  a  compilation  unit  is  compiled  without 
error,  the  current  program  library  is  updated  with  the  object  module 
and  other  products  of  the  compilation. 


Command  Qualifiers 

(LIBRARY  *  directory-spec 

Specifies  the  program  library  that  is  to  be  the  current  program  library 
for  the  duration  of  the  compilation.  The  directory  specified  must  be  an 
already  existing  XD  Ada  program  library.  No  wildcard  characters  are 
allowed  in  the  directory  specification. 

By  default,  the  current  program  library  is  the  program  library  last 
specified  in  an  XDACS  SET  LIBRARY  command.  The  logical  name 
XDADASLJB  is  assigned  to  the  program  library  specified  in  an  XDACS 
SET  LIBRARY  command. 


Positional  Qualifiers 

/ ANALYSI$_DATA(  •  file-spec] 

/NOANALYSIS JDATA  (D) 

Controls  whether  a  data  analysis  file  containing  source  code  cross- 
reference  and  static  analysis  information  is  created.  The  data  analysis 
file  is  supported  only  for  use  with  DIGITAL  layered  products,  sucn  as 
the  VAX  Source  Code  Analyzer. 


XDADA 


One  data  analysis  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  data  analysis  files  is  the  current  default  directory. 
The  default  file  name  is  the  name  of  the  source  file  being  compiled. 

The  default  file  type  is  .ANA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  data  analysis  file  is  created. 

/ CHECK 
/NOCHECK 

Controls  whether  all  run-time  checks  are  suppressed.  The  /NOCHECK 
qualifier  is  equivalent  to  having  all  possible  SUPPRESS  pragmas  in  the 
source  code. 

Explicit  use  of  the  /CHECK  qualifier  overrides  any  occurrences  of  the 
pragmas  SUPPRESS  and  SUPPRESS. ALL  in  the  source  code,  without 
the  need  to  edit  the  source  code. 

By  default,  run-time  checks  are  suppressed  only  in  cases  where  a 
pragma  SUPPRESS  or  SUPPRESS. ALL  appears  in  the  source. 

See  the  Reference  Manual  for  the  Ada  Programming  Language  for  more 
information  on  the  pragmas  SUPPRESS  and  SUPPRESS.ALL. 

ICOPY_SOURCE  (D) 

INOCOPYJSOURCE 

Controls  whether  a  copied  source  file  (.ADC)  is  created  in  the  current 
program  library  when  a  compilation  unit  is  compiled  without  error.  The 
RECOMPILE  command  (and  thus  the  COMPILE  command)  requires 
that  a  copied  source  file  exist  in  the  current  program  library  for  any  unit 
that  is  to  be  recompiled. 

By  default,  a  copied  source  file  is  created  in  the  current  program  library 
when  a  unit  is  compiled  without  error. 

IDEBUQf  ■  (optlon[, . . .])]  (D) 

INODEBUQ 

Controls  which  compiler  debugging  options  are  provided.  You  can 
debug  XD  Ada  programs  with  the  XD  Ada  Debugger.  You  can  request 
the  following  options: 
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ALL 

NONE 

[NOISYMBOLS 

(NO|TRACEBACK 


By  default,  both  debugger  symbol  records  and  traceback  information  are 
included  in  the  object  file  (/DEBUG -ALL,  or  equivalently:  /DEBUG). 

IDIAQNOSTICSl  *  fill-spec] 

/NODI AGNOSTICS  (D) 

Controls  whether  a  diagnostics  file  containing  compiler  messages  and 
diagnostic  information  is  created.  The  diagnostics  file  is  supported  only 
for  use  with  DIGITAL  layered  products,  such  as  the  VAX  Language- 
Sensitive  Editor. 

One  diagnostics  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  diagnostics  files  is  the  current  default  directory. 

The  default  file  name  is  the  name  of  the  source  file  being  compiled. 

The  default  file  type  is  .DIA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  diagnostics  file  is  created. 

lERROBJUMIT] »  n] 

I NOERRORJJMIT 

Controls  whether  execution  of  the  XDADA  command  for  a  given 
compilation  unit  is  terminated  upon  the  occurrence  of  the  nth  E-level 
error  within  that  unit. 

Error  counts  are  not  accumulated  across  a  sequence  of  compilation 
units.  If  the  /ERROR_LIMIT-n  option  is  specified,  each  compilation 
unit  may  have  up  to  n-1  errors  without  terminating  the  compilation. 
When  the  error  limit  is  reached  within  a  compilation  unit,  compilation  of 
that  unit  is  terminated,  but  compilation  of  subsequent  units  continues. 

The  /ERROR_LIMIT-0  option  is  equivalent  to  ERROR_LIMIT-l. 

By  default,  execution  of  the  XDADA  command  is  terminated  for  a  given 
compilation  unit  upon  the  occurrence  of  the  30th  E-level  error  within 
that  unit  (equivalent  to  /ERROR.. LIMIT  -  30). 


Provides  both  SYMBOLS  and  TRACEBACK, 

Provides  neither  SYMBOLS  nor  TRACEBACK. 

Controls  whether  debugger  symbol  records  are  in¬ 
cluded  in  the  object  file. 

Controls  whether  traceback  information  (a  subset  of 
the  debugger  symbol  information)  is  included  in  the 
object  file. 
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/LIST]  •file-spec] 

I  NOLIST  (D) 

Controls  whether  a  listing  file  is  created.  One  lifting  file  is  created 
for  each  source  file  compiled.  The  default  directory  for  listing  files  is 
the  current  default  directory.  The  default  file  name  is  the  name  of  the 
source  file  being  compiled.  The  default  file  type  is  .US.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  the  XDADA  command  does  not  create  a  listing  file. 

/LOAD]  m  option]  (D) 

INOLOAD 

Controls  whether  the  current  program  library  is  updated  with  the 
successfully  processed  units  contained  in  the  specified  source  files. 
Depending  on  other  qualifiers  specified  (or  not  specified)  with  the 
XDADA  command,  processing  can  involve  full  compilation,  syntax 
checking  only,  and  so  on.  The  /NOLOAD  qualifier  causes  the  units 
in  the  specified  source  files  to  be  processed,  but  prevents  the  current 
program  library  from  being  updated. 

You  can  specify  the  following  option: 

(NO)REPLACE  Controls  whether  a  unit  added  to  the  current 

program  library  replaces  an  existing  unit  with  the 
same  name.  If  you  specify  the  NOREPLACE  option, 
the  unit  is  added  to  the  current  program  library  only 
if  no  existing  unit  has  the  same  name,  except  if  the 
new  unit  is  the  corresponding  body  of  an  existing 
specification  or  vice  versa. 

By  default,  the  current  program  library  is  updated  with  the  success¬ 
fully  processed  units,  and  a  unit  added  to  the  current  program  library 
replaces  an  existing  unit  with  the  same  name. 

IMACHINcjCODE]*  option] 

INOMACHINE_CODE  (0) 

Controls  whether  generated  machine  code  (approximating  assembly 
language  notation)  is  included  in  the  listing  file. 

You  can  specify  one  of  the  following  options: 
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SYMBOLIONONE  T rovides  machine  code  listing  with  no  annotation. 

SYMBOLIONORMAL  Provides  machine  code  in  the  listing  file;  where 

possible,  instructions  are  annotated  with  simple 
Ada  names. 

SYMBOL1GMAXIMAL  Provides  machine  code  in  the  listing  file;  where 

possible,  instructions  are  annotated  with  Ada 
names,  in  expanded  form  if  necessary. 

The  /MACHINE_CODE  qualifier  without  options  is  equivalent  to 
/MACHINE_CODE  -  SYMBOLIONORMAL. 

By  default,  generated  machine  code  is  not  included  in  the  listing  file. 

tNOTEJOURCE  (D) 

I  NONOTE  _SOURCE 

Controls  whether  the  file  specification  of  the  source  file  is  noted  in  the 
program  library  when  a  unit  is  compiled  without  error.  The  COMPILE 
command  uses  this  information  to  locate  revised  source  files. 

By  default,  the  file  specification  of  the  source  file  is  noted  in  the  pro¬ 
gram  library  when  a  unit  is  compiled  without  error. 

/OPTIMIZE!  *(optlon[,  . . .  J) 

INOOPTIMIZE 

Controls  the  level  of  optimization  that  is  applied  in  producing  the 
compiled  code.  You  can  specify  one  of  the  following  primary  options: 

TIME 


SPACE 


DEVELOPMENT 
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Provides  full  optimization  with  time  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(SPACE)  in  the  source  code. 

Provides  full  optimization  with  space  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(TIME)  in  the  source  code. 

Suggested  when  active  development  of  a  program 
is  in  progress.  Provides  some  optimization,  but 
development  considerations  and  ease  of  debugging 
take  preference  over  optimization.  This  option 
overrides  pragmas  that  establish  a  dependence  on  a 
subprogram  (the  pragma  INLINE),  and  thus  reduces 
the  need  for  recompilations  when  such  bodies  are 
modified. 


NONE  Provides  no.  optimization.  Suppresses  expansions  in 

line  of  subprograms,  including  those  specified  by  the 
pragma  INLINE. 

The  /NOOPTIMIZE  qualifier  is  equivalent  to  /OPTIMIZE -NONE. 

By  default,  the  XDADA  command  applies  full  optimization  with  space 
as  the  primary  optimization  criterion  (like  /OPTIMIZE -SPACE,  but 
observing  uses  of  the  pragma  OPTIMIZE). 

The  /OPTIMIZE  qualifier  also  has  a  set  of  secondary  options  that  you 
can  use  separately  or  together  with  the  primary  options  to  override  the 
default  behavior  for  inline  expansion  and  code  motion. 

i 

The  INLINE  secondary  option  can  have  the  following  values: 

INL1NE:N0NE  Disables  subprogram  expansion  in  line.  This  option 

overrides  any  occurrences  of  the  pragma  INLINE 
in  the  source  code,  without  having  to  edit  the 
source  file,  it  also  disables  implicit  expansion  in 
line  of  subprograms.  ( Implicit  expansion  in  line  means 
that  the  compiler  assumes  a  pragma  INLINE  for 
certain  subprograms  as  an  optimization.)  A  call  to  a 
subprogram  in  another  unit  is  not  expanded  in  line, 
regardless  of  the  /OPTIMIZE  options  in  effect  when 
that  unit  was  compiled. 

INUNE:NORMAL  Provides  normal  subprogram  expansion  in  line. 

Subprograms  to  which  an  explicit  pragma  INLINE 
applies  are  expanded  in  line  under  certain  condi¬ 
tions.  In  addition,  some  subprograms  are  implicitly 
expanded  in  line.  The  compiler  assumes  a  pragma 
INLINE  for  calls  to  some  small  local  subprograms 
(subprograms  that  are  declared  in  the  same  unit  as 
the  unit  in  which  the  call  occurs). 

INUNE:SUBPROGRAMS  Provides  maximal  subprogram  expansion  in  line.  In 
addition  to  the  normal  subprogram  expansion  in 
line  that  occurs  when  1NUNE:N0RMAL  is  specified, 
this  option  results  in  implicit  expansion  in  line  of 
some  small  subprograms  declared  in  other  units. 

The  compiler  assumes  a  pragma  INLINE  for  any 
subprogram  if  it  improves  execution  speed  and 
reduces  code  size.  This  option  may  establish  a 
dependence  on  the  body  of  another  unit,  as  would  be 
the  case  if  a  pragma  INLINE  were  specified  explicitly 
in  the  source  code. 
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INUNE:MAX1MAL  Provides  maximal  subprogram  expansion  in  line. 

Maximal  subprogram  expansion  in  line  occurs  as  for 
INL1NE:SUBPR0GRAMS. 

INLINE: GENERICS  Provides  normal  subprogram  inline  expansion  and 

maximal  generic  inline  expansion.  With  this  option, 
subprogram  inline  expansion  occurs  in  the  same 
manner  as  for  INUNE:NORMAL.  The  compiler 
assumes  a  pragma  INUNE.GENERIC  for  every 
instantiation  in  the  unit  being  compiled  unless 
a  generic  body  is  not  available.  This  option  may 
establish  a  dependence  on  the  body  of  another  unit, 
as  wouid  be  the  case  if  a  pragma  INUNE.GENERIC 
were  specified  explicitly  in  the  source  code. 

The  MOTION  secondary  option  can  have  the  following  values: 
MOT10N:NON£  Disables  code  motion  optimizations. 

MOTION: LOOPS  Permits  code  motion  optimization  of  loops.  Where 

the  compiler  detects  that  a  loop  body  contains 
invariant  processing,  it  may  generate  code  in  which 
this  processing  is  performed  before  entry  to  the  loop 
instead  of  within  the  loop. 

MOTION :  MAXIMAL  Permits  all  code  motion  optimizations.  In  addition 

to  the  optimization  of  loops  that  occurs  when 
MOTION:LOOPS  is  specified,  this  option  permits 
analogous  optimization  of  if  and  case  statements: 
where  the  compiler  detects  that  the  branches  of  an  if 
or  case  statement  contain  common  processing,  it  may 
generate  code  in  which  this  processing  is  performed 
before  evaluation  of  the  corresponding  condition  or 
case  expression  instead  of  within  the  branches. 

By  default,  the  /OPTIMIZE  qualifier  primary  options  have  the  following 
secondary-option  values: 

/OPTIM1ZE-TIME  «(INUNE:NORMAL,MOTION:LOOPS) 

/OPTIMIZE- SPACE  »(INUNE:NORMAL,MOTION:MAXIMAL) 

/OPTIMIZE  -  DEVELOPMENT  -  (INUNE:NONE,MOTION:NONE) 

/OPTIMIZE -NONE  -(lNUNE:NONE,MOTION:NONE) 

/PREDEFINED  JJNIT 
INOPREDEFINEDJUNIT  (D) 

Controls  the  compilation  of  package  $RUN_TIME_SYSTEM,  package 
STASKING.SYSTEM,  and  package  MACHINE.CODE.  You  must  spec¬ 
ify  this  qualifier  in  order  to  be  able  to  compile  these  packages.  The 
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qualifier  is  not  required  for  the  compilation  of  any  other  source  fi le« 

£££/'*  M"-STD175tM  *«&- 

By  default,  /PREDEFINED. UNIT  is  omitted. 

ISHOW[  m  option]  (D) 

/NOSHOW 

Controls  the  listing  file  options  included  when  a  listing  file  is  provided 
You  can  specify  one  of  the  following  options:  *  p  ea' 

ALL  Provides  all  listing  file  options. 

(NO)PORTABIUTY  Controls  whether  a  program  portability  summary 

lauded  m  the  listing  file.  By  default,  the 
xu  AD  A  command  provides  a  portability  sum- 
mary  (/SHOW. PORTABILITY).  See  Appendix  E 
for  details  of  what  can  be  included  in  a  porta- 
btiity  summary.  See  Chapter  5  of  Version  2.0  of 
Developing  Ada  Programs  or  VMS  Systems  for  more 
information  on  program  portability. 

N0NE  ShOW*  °f  **  ,iSUn8  fUe  °pti0ns  (same  “ 

^SHOW-PORTABlUTl^0mmai,<*  pr0Vide5  *  <’°rtabUi'>' 

ISYNTAXJONLY 
INOSYNTAXjONLY  (D) 

Controls  whether  the  source  file  is  to  be  checked  only  for  correct  syntax. 
If  you  specify  the  /SYNTAX.ONLY  qualifier,  other  compiler  check™* 
not  performed  (for  example,  semantic  analysis,  type  checking,  and  so 

th* 'L0AD-rEPLACE  qualifier  (the  default),  the 
/SYNTAX.ONLY  qualifier  updates  the  current  program  library  with 
syntax-checked-only  units.  The  units  are  considered  to  be  obsolete  and 
must  be  subsequently  recompiled. 

In  the  presence  of  the  /NOLOAD  qualifier,  the  /SYNTAX.ONLY  qual- 
j™r  C^eC^S  synta*  the  specified  units  but  does  not  update  me 

By  default,  the  compiler  performs  all  checks. 
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IWARNINQS[  *  (message-optlon[, ...])] 

INOWARNINQS 

Controls  which  categories  of  informational  (I-levei)  and  warning  (W- 
level)  messages  are  displayed  and  where  those  messages  ere  displayed. 
You  can  specify  any  combination  of  the  following  message  options: 

WARNINGS:  (£tesfmafton(,...l) 

NOWARNINGS 


WEAK  WARNINGS:  (destination],...]) 
NOWEAK.  WARNINGS 

SUPPLEMENTAL:  (destination], . . .]) 
NOSUPPLEMENT  AL 


COMPILATION. NOTES :  (destination\,... )) 
NOCOMPILATION.NOTES 


STATUS:  (destination],...]) 

NOSTATUS 

The  possible  values  of  destination  are  ALL,  NONE,  or  any  combination 

of  TERMINAL  (terminal  device),  LISTING  (listing  file),  DIAGNOSTICS 

(diagnostics  file).  The  message  categories  are  summarized  as  follows: 

WARNINGS  W-Ievel:  Indicates  a  definite  problem  in  a  legal 

program,  for  example,  an  unknown  pragma. 

WEAK.WARNINGS  I-Ievel:  Indicates  a  potential  problem  in 

a  legal  program;  for  example,  a  possible 
CUNSTRAINT.ERROR  at  run  time.  These 
are  the  only  kind  of  1-level  messages  that  are 
counted  in  the  summary  statistics  at  the  end  of 
a  compilation. 

SUPPLEMENTAL  I-level:  Additional  information  associated  with 

preceding  E-level  or  W-Ievel  diagnostics. 

COMPILATION.NOTES  1-level:  Information  about  how  the  compiler 

translated  a  program,  such  as  record  layout, 
parameter-passing  mechanisms,  or  decisions 
made  for  the  pragmas  INLINE,  INTERFACE,  or 
the  import-subprogram  pragmas. 

STATUS  (-level:  End  of  compilation  statistics  and  other 

messages. 
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The  defaults  are  as  follows. 

/WARNINGS- ( WARN: ALL, WEAK  t  ALL, SUPP: ALL, COMP: NONE, SXAT : LIST ) 

Note  that  abbreviations  are  valid. 

If  you  specify  only  some  of  the  message  categories  with  the 
/WARNINGS  qualifier,  the  default  values  for  other  categories  are  used. 


Examples 

1.  S  XDADA  MODEL. INTERFACE., MODEL. INTERFACE, CONTROL.LOOP 

The  XDADA  command  compiles  the  compilation  units  con¬ 
tained  in  the  three  files  MODEL_INTERFACE_.ADA,  MODEL. 
INTERFACE. ADA,  and  CONTROL.LOOP.ADA,  in  the  order  given. 

2.  $  XDADA/LI ST / SHOW-ALL  SCREEN. IO_ , SCREEN.IO 

The  XDADA  command  compiles  the  compilation  units  contained 
in  the  two  files  SCREEN.IO_.ADA  and  SCREEN.IO.ADA,  in  the 
order  given.  The  /LIST  qualifier  creates  the  listing  files  SCREEN. 
IO..LIS  and  SCREEN.IO.US  in  the  current  default  directory.  The 
/SHOW  -  ALL  qualifier  causes  all  listing  file  options  to  be  provided 
in  the  listing  files. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  linker 
documentation  and  not  to  this  report. 


Validation  Summary  Report 
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Creates  an  executable  image  file  for  the  specified  units  At  Version 
1.2,  a  new  qualifier,  /SELECTIVE  is  suoniioH  :  version 

specification  is  given  for  convenience  PP  COmPlete  COmmand 


Command  Qualifiers 
/AFTER*  time 
/BATCH_LOG  *  file-spec 
/BRIEF 

/COMMAND!  *  file-spec) 
/(NOIDEBUG 

/ELABORATION  *  file-spec 
/  FULL 

/[NOjlMAGE[  *  file-spec] 
/(NO)KEEP 
/{NOJLOG 
/[NOJMAIN 

/[NOJMAPI  *  file-spec) 

/NAME -job-name 

/(NOJNOTIFY 

/OUTPUT -file-spec 

/(NO)PRINTERj »  queue-name) 

/QUEUE  -  queue-name 

/{NOJSELECTIVE 

/SUBMIT 

/WAIT 

Parameter  Qualifiers 
/LIBRARY 
/MAPPING 
/TARGET 


Defaults 
/AFTER -TODAY 
See  text. 

See  text. 

See  text. 

/NODEBUG 
See  text. 

See  text. 

/IMAGE 

/KEEP 

/NOLOG 

/MAIN 

/NOMAP 

See  text. 

/NOTIFY 

/OUTPUT -  SYSJOUTPUT 

/NOPRINTER 

/QUEUE -SYS$BATCH 

/SELECTIVE 

/WAIT 

/WAIT 

Defaults 
See  text. 

See  text. 

See  text. 
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Prompts 


Unit: 

.File: 


Command  Parameters 

unit-name 

By  default  (or  if  you  specify  the  /MAIN  qualifier): 

•  You  can  specify  up  to  16  units  (one  per  address  state),  the  source 
code  of  which  must  be  written  in  XD  Ada. 

•  The  parameter  unit-name  specifies  an  XD  Ada  main  program,  which 
must  be  a  procedure  with  no  parameters. 

The  /NOMAIN  qualifier  can  only  be  used  with  a  single  address  state 
program.  If  you  specify  the  /NOMAIN  qualifier: 

•  You  can  specify  one  or  more  foreign  units  that  are  to  be  included 
in  the  executable  image.  The  unit  names  may  include  percent  signs 
(%)  and  asterisks  (*)  as  wildcard  characters.  (See  the  VMS  DCL 
Concepts  Manual  for  detailed  information  on  wildcard  characters.) 

•  The  image  transfer  address  comes  from  one  of  the  foreign  files 
specified. 

flla-spec 

Specifies  a  list  of  object  files,  object  libraries,  mapping  definition  files, 
and  target  definition  files,  that  are  to  be  used  in  linking  the  program. 
The  default  directory  is  the  current  default  directory.  The  default  file 
type  is  .XOB,  unless  the  /LIBRARY,  /MAPPING,  or  /TARGET  qualifier  is 
used.  No  wildcard  characters  are  allowed  in  a  file  specification. 

If  the  file  is  an  object  library,  you  must  use  the  /LIBRARY  qualifier.  The 
default  file  type  is  .XLB. 

If  the  file  is  a  mapping  definition  file,  you  must  use  the  /MAPPING 
qualifier.  The  default  file  type  is  .MPD. 

If  the  file  is  a  target  definition  file  you  must  use  the  /TARGET  qualifier. 
The  default  file  type  is  .TGD. 

If  you  specify  the  /NOMAIN  qualifier,  the  image  transfer  address  comes 
from  one  of  the  files  (not  units)  specified.. 
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For  a  multiple  program  build,  the  list  of  foreign  file  specifications  will 
be  included  in  the  build  for  each  program  in  each  address  state. 


Description 

The  LINK  command  performs  the  following  steps: 

1.  Runs  the  prebuild  phase  to  generate  an  elaboration  list. 

2.  Checks  if  a  pragma  LINK.OPTION  is  specified  for  the  main  pro¬ 
gram,  and  if  specified,  verifies  that  the  designated  link  option  name 
is  available  in  the  current  program  library.  If  available,  the  copied 
link  option  files  in  the  library  corresponding  to  the  link  option  are 
used,  unless  overridden  by  the  /TARGET  or  /MAPPING  qualifiers. 

Note  that,  unlike  the  CHECK  command,  the  pragma  LINK, 
OPTION  association  for  units  other  than  the  main  program  unit 
is  net  checked. 

If  no  target  link  option  is  given  for  the  main  program  unit  or  the 
designated  target  link  option  is  not  found  in  the  library,  and  the 
logical  name  XDADA$TARGET_DEF  is  not  defined,  and  a  /TARGET 
qualifier  is  not  specified  on  the  LINK  command  line,  an  error  is 
issued.  If  no  mapping  link  option  is  given  for  the  main  program  unit 
or  the  designated  mapping  link  option  is  not  found  in  the  library, 
and  the  logical  name  XDADA$MAPPING_DEF  is  not  defined,  and  a 
/MAPPING  qualifier  is  not  specified  on  the  XDACS  LINK  command 
line,  the  default  mapping  in  the  target  definition  file  is  used. 

3.  If  LINK/NOMAIN  is  not  specified,  checks  that  only  one  unit  is 
specified  and  that  it  is  an  XD  Ada  main  program. 

4.  Forms  the  closure  of  the  main  program  (LINK/MAIN)  or  of  the 
specified  units  (LINK/NOMAIN)  and  verifies  that  all  units  in  the 
closure  are  present,  current  and  complete.  If  XDACS  detects  an 
error,  the  operation  is  terminated  at  the  end  of  the  prebuild  phase. 

5.  Creates  a  DCL  command  file  for  the  builder.  The  command  file  is 
deleted  after  the  LINK  operation  is  completed  or  terminated,  unless 
LINK/COMMAND  is  specified.  If  LINK/COMMAND  is  specified, 
the  command  file  is  retained  for  future  use,  and  the  build  phase  is 
not  carried  out. 

6.  Unless  the  /COMMAND  qualifier  is  specified,  performs  the  build 
phase  as  follows: 

a.  By  default  (LINK/WAIT),  the  command  file  generated  in  step 
5  is  executed  in  a  subprocess.  You  must  wait  for  the  build 
operation  to  terminate  before  issuing  another  command.  Note 


LINK 


that  when  you  specify  the  /WAIT  qualifier  (the  default),  process 
logical  names  are  propagated  to  the  subprocess  generated  to 
execute  the  command  file. 

b.  If  you  specify  the  /SUBMIT  qualifier,  the  builder  command  file 
is  submitted  as  a  batch  job. 

7.  If  the  /DEBUG  qualifier  is  included  in  the  command  line  the  debug 
symbol  table  information  is  placed  in  the  .XXE  file. 

8.  Creates  a  loadable  output  file  with  a  default  file  type  of  .XXE. 

XDACS  output  originating  before  the  builder  is  invoked  is  reported 
to  your  terminal  by  default,  or  to  a  file  specified  with  the  /OUTPUT 
qualifier.  Diagnostics  are  reported  to  your  terminal,  by  default,  or  to 
a  log  file  if  the  LINK  command  is  executed  in  batch  mode  (XDACS 
UNK/SUBMIT). 

See  Chapter  7,  Chapter  8,  and  Chapter  9  for  more  information  on  the 
XD  Ada  target-specific  builder  commands. 


Command  Qualifiers 

I  AFTER  ■  tlm§ 

Requests  that  the  batch  job  be  held  until  after  a  specific  time,  when 
the  LINK  command  is  executed  in  batch  mode  (UNK/SUBMIT).  If  the 
specified  time  has  already  passed,  the  job  is  queued  for  immediate 
processing. 

You  can  specify  either  an  absolute  time  or  a  combination  of  absolute 
and  delta  time.  See  the  VMS  DCL  Concepts  Manual  (or  type  HELP 
Specify  Date-Time  at  the  DCL  prompt)  for  complete  information  on 
specifying  time  values. 

/BATCH  _LOQ  ■  fllt-sptc 

Provides  a  file  specification  for  the  batch  log  file  when  the  UNK  com¬ 
mand  is  executed  in  batch  mode  (UNK/SUBMIT). 

If  you  do  not  give  a  directory  specification  with  the  file-spec  option,  the 
batch  log  file  is  created  by  default  in  the  current  default  directory.  If 
you  do  not  give  a  file  specification,  the  default  file  name  is  the  job  name 
specified  with  the  /NAME -job-name  qualifier.  If  no  job  name  has  been 
specified,  the  program  library  manager  creates  a  file  name  comprising 
up  to  the  first  39  characters  of  the  first  unit  name  specified.  If  you 
specified  LINK /NOM AIN  and  no  job  name  and  there  is  a  wildcard 
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LINK 


character  in  the  first  unit  specified,  the  program  library  manager  uses 
the  default  file  name  XDACS_LINK.  The  default  file  type  is  .LOG. 

/ BRIEF 

Directs  the  builder  to  produce  a  brief  image  map  file.  The  /BRIEF 
qualifier  is  valid  only  if  you  also  specify  the  /MAP  qualifier  with  the 
LINK  command.  The  /BRIEF  qualifier  is  incompatible  with  the  /FULL 
qualifier. 

A  brief  image  map  file  contains  only  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Link  run  statistics 

See  also  the  description  of  the  /FULL  qualifier. 

ICOMMANDl  *  fllt-sptc] 

Controls  whether  the  builder  is  invoked  as  a  result  of  the  LINK  com¬ 
mand,  and  determines  whether  the  command  file  generated  to  invoke 
the  builder  is  saved.  If  you  specify  the  /COMMAND  qualifier,  XDACS 
does  not  invoke  the  builder,  and  the  generated  command  file  is  saved 
for  you  to  invoke  or  submit  as  a  batch  job. 

The  file-spec  option  allows  you  to  enter  a  file  specification  for  the  gen¬ 
erated  command  file.  The  default  directory  for  thr  command  file  is  the 
current  default  directory.  By  default,  XDACS  provides  a  file  name  com¬ 
prising  up  to  the  first  39  characters  of  the  first  unit  name  specified.  If 
you  specified  LINK/NOMA1N  and  you  used  a  wildcard  character  in  the 
.  first  unit  name  specified,  the  program  library  manager  uses  the  default 
file  name  XDACS_LINK.  The  default  file  type  is  .COM.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  if  the  /COMMAND  qualifier  is  not  specified,  XDACS  deletes 
the  generated  command  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/DEBUG 
/NODEBUG  (D) 

Controls  whether  a  debugger  symbol  table  is  generated  in  the  loadable 
image  file. 

By  default,  no  debugger  symbol  table  is  created. 
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/ELABORATION  •  flla-spac 

Provides  a  file  specification  for  the  text  file  generated  by  the  LINK 
command.  The  file  is  retained  by  XDACS  only  when  the  /COMMAND 
qualifier  is  used:  that  is,  when  the  result  of  the  LINK  operation  is  to 
produce  a  builder  command  file  for  future  use,  rather  than  to  invoke  the 
builder  immediately. 

The  generated  text  file  contains  the  table  that  directs  the  elaboration  of 
library  packages  in  the  closure  of  the  units  specified.  Unless  you  also 
specify  the  /NOMAIN  qualifier,  the  text  file  also  contains  the  image 
transfer  address. 

The  default  directory  for  the  generated  text  file  is  the  current  default 
directory.  The  default  file  type  is  .ELB.  No  wildcard  characters  are 
allowed  in  the  file  specification. 

By  default,  if  you  do  not  specify  the  /ELABORATION  qualifier,  XDACS 
provides  a  file  name  comprising  up  to  the  first  39  characters  of  the  first 
unit  name  specified. 

By  default,  if  you  do  not  specify  the  /COMMAND  qualifier,  XDACS 
deletes  the  generated  text  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/FULL 

Directs  the  builder  to  produce  a  full  image  map  file,  which  is  the  most 
complete  image  map.  The  /FULL  qualifier  is  valid  only  if  you  also 
specify  the  /MAP  qualifier  with  the  LINK  command.  Also,  the  /FULL 
qualifier  is  incompatible  with  the  /BRIEF  qualifier. 

A  full  image  map  file  contains  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Symbol  address  information 

•  Exception  numbers 

•  Link  run  statistics 

nMAQE(mfUt-ap9C]  (D) 

INOIMAQE 

Controls  whether  the  LINK  command  creates  a  loadable  image  file  and 
optionally  provides  a  file  specification  for  the  file.  The  default  file  type 
is  .XXE.  No  wildcard  characters  are  allowed  in  the  file  specification. 


LINK 


By  default,  an  executable  image  file  is  created  with  a  file  name  compris¬ 
ing  up  to  the  first  39  characters  of  the  first  unit  name  specified. 

/KEEP  (D) 

/NOKEEP 

Controls  whether  the  batch  log  tile  generated  is  deleted  after  it 
is  printed  when  the  LINK  command  is  executed  in  batch  mode 
(UNK/SUBMIT). 

By  default,  the  log  file  is  not  deleted. 

/LOG 

INQLOQ  (D) 

Controls  whether  a  list  of  all  the  units  included  in  the  executable  image 
is  displayed.  The  display  shows  the  units  according  to  the  order  of 
elaboration  for  the  program. 

By  default,  a  list  of  all  the  units  included  in  the  executable  image  is  not 
displayed. 

/ MAIN  (D) 

INOMAIN 

Controls  where  the  image  transfer  address  is  to  be  found. 

The  /MAIN  qualifier  indicates  that  the  XD  Ada  unit  specified  deter¬ 
mines  the  image  transfer  address,  and  hence  is  to  be  a  main  program. 

The  /NOMAIN  qualifier  indicates  that  the  image  transfer  address  comes 
from  one  of  the  tiles  specified,  and  not  from  one  of  the  XD  Ada  units 
specified. 

By  default  (/MAIN),  only  one  XD  Ada  unit  can  be  specified,  and  that 
unit  must  be  an  XD  Ada  main  program. 

IMAPlmfilwc] 

INOMAP  (D) 

Controls  whether  the  builder  creates  an  image  map  file  and  optionally 
provides  a  file  specification  for  the  file.  The  default  directory  for 
the  image  map  file  is  the  current  directory.  The  default  file  name 
comprises  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
The  default  file  type  is  .MAP.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

If  neither  the  /BRIEF  nor  the  /FULL  qualifier  is  specified  with  the  / MAP 
qualifier,  /BRIEF  is  assumed. 
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By  default,  no  image  map  file  is  created. 

/NAME  m  job-name 

Specifies  a  string  to  be  used  as  the  job  name  and  as  the  file  name  for 
the  batch  log  file  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT).  The  job  name  can  have  from  1  to  39  characters. 

By  default,  if  you  do  not  specify  the  /NAME  qualifier,  XDACS  creates 
a  job  name  comprising  up  to  the  first  39  characters  of  the  first  unit 
name  specified.  If  you  specify  LINK/NOMAIN  but  do  not  specify  the 
/NAME  qualifier,  and  you  use  a  wildcard  character  in  the  first  unit 
name  specified,  the  program  library  manager  uses  the  default  file  name 
XDACS.LINK.  In  these  cases,  the  job  name  is  also  the  file  name  of  the 
batch  log  file. 

/NOTIFY  (D) 

INONOTIFY 

Controls  whether  a  message  is  broadcast  when  the  LINK  command  is 
executed  in  batch  mode  (UNK/SUBMIT).  The  message  is  broadcast  to 
any  terminal  at  which  you  are  logged  in,  notifying  you  that  your  job  has 
been  completed  or  terminated 

By  default,  a  message  is  broadcast. 

CiJTPUT  •  file-spec 

Requests  that  any  output  generated  before  the  builder  is  invoked  be 
written  to  the  file  specified  rather  than  to  SYSSOUTPUT.  Any  diagnostic 
messages  are  written  to  both  SYSSOUTPUT  and  the  file. 

The  default  directory  is  the  current  default  directory.  If  you  specify  a 
file  type  but  omit  the  file  name,  the  default  file  name  is  XDACS.  The 
default  file  type  is  .LIS.  No  wildcard  characters  are  allowed  in  the  file 
specification. 

By  default,  the  LINK  command  output  is  written  to  SYSSOUTPUT. 

/ PRINTER [  m  queue-name] 

INOPRINTER  (D) 

Controls  whether  the  log  file  is  queued  for  printing  when  the  LINK 
command  is  executed  in  batch  mode  (LINK/SUBMIT)  and  the  batch  job 
is  completed. 

The  /PRINTER  qualifier  allows  you  to  specify  a  particular  print  queue. 
The  default  print  queue  for  the  log  file  is  SYSSPRINT. 


LINK 


By  default,  the  log  file  is  not  queued  for  printing.  If  you  specify 
/NOPRINTER,  /KEEP  is  assumed. 

/QUEUE  *  queue-name 

Specifies  the  batch  job  queue  in  which  the  job  is  entered  when  the 
LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT). 

By  default,  if  the  /QUEUE  qualifier  is  not  specified,  the  job  is  placed  in 
the  default  system  batch  job  queue,  ''YSSBATCH. 

/SELECTIVE  (D) 

INOSELECTIVE 

Specifies  whether  selective  linking  is  performed. 

Performing  selective  linking  ensures  that  only  subprograms  that  are 
called  will  be  linked  into  the  program  image.  Subprograms  within  the 
closure  of  the  main  program  that  are  not  actually  called  will  be  omitted 
from  the  image  file.  Selective  linking  produces  a  program  image  that 
has  been  optimized  according  to  size. 

Non-selective  linking  ensures  that  all  defined  subprograms  are  linked 
into  the  image. 

By  default,  selective  linking  is  performed. 

/SUBMIT 

Directs  XDACS  to  submit  the  command  file  generated  for  the  builder 
to  a  batcn  queue.  You  can  continue  to  issue  commands  in  your  current 
process  without  waiting  for  the  bu<ch  job  to  complete.  The  builder 
output  is  written  to  a  batch  log  file. 

By  default,  the  generated  command  file  is  executed  in  a  subprocess 
(LINK /WAIT). 

/WAIT 

Directs  XDACS  to  execute  the  command  file  generated  for  the  builder 
in  a  subprocess.  Execution  of  your  current  process  is  suspended  until 
the  subprocess  completes.  The  builder  output  is  written  directly  to 
your  terminal.  Note  that  process  logical  names  are  propagated  to  the 
subprocess  generated  to  execute  the  command  file. 

By  default,  XDACS  executes  the  command  file  generated  for  the  builder 
in  a  subprocess:  you  must  wait  for  the  subprocess  to  terminate  before 
you  can  issue  another  command. 


LINK 


Parameter  Qualifiers 

/LIBRARY 

Indicates  that  the  associated  input  file  is  an  object  module  library  to  be 
searched  for  modules  to  resolve  any  undefined  symbols  in  the  input 
files.  The  default  file  type  is  .XLB. 

By  default,  if  you  do  not  specify  the  /LIBRARY  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/MAPPING 

Indicates  that  the  associated  input  file  is  a  mapping  definition  file. 
Mapping  definition  files  control  the  location  of  the  program  on  the 
target  system.  The  default  file  type  is  .MPD. 

By  default,  if  you  do  not  specify  the  /MAPPING  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/ TARGET 

Indicates  that  the  associated  input  file  is  a  target  definition  file.  Target 
definition  files  describe  the  target  system's  memory.  The  default  file 
type  is  .TGD. 

By  default,  if  you  do  not  specify  the  /TARGET  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 


Examples 

1  XDACS>  LINK  CONTROL_LOOP 

%ACS-I-CL_LINKING,  Invoking  the  XD  Ada  Builder 

The  LINK  command  forms  the  closure  of  the  unit  CONTROL, 
LOOP,  which  is  an  XD  Ada  main  program,  creates  a  builder  com¬ 
mand  file  and  package  elaboration  file,  then  invokes  the  command 
file  in  a  spawned  subprocess. 

2.  XDACS>  LINK/SUBMIT  CONTROL_LOOP  LOOP_FUNCTIONS/LIBRARY 

\ACS-I-CL_SUBMITTED,  Job  CONTROL_LOOP  (queue  ALL_BATCH,  entry  134) 
started  on  FAST_BATCH 

The  LINK  command  instructs  the  builder  to  link  the  closure  of  the 
XD  Ada  main  program  CONTROL_LOOP  against  the  library  LOOP. 
FUN CTION S . XLB .  The  /SUBMIT  qualifier  causes  XDACS  to  submit 
the  builder  command  file  as  a  batch  job. 


/ 
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3. 


XDACS>  LINK/NOMAIN  FLUID, VOLUME, COUNTER  MONITOR. X09 
%ACS-I-CL_LINKING,  Invoking  the  XD  Ada  Builder 


APPENDIX  F  OF  THE  Ada  STANDARD 


APPENDIX  C 

APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to  implementation-dependent  pragmas, 
to  certain  machine-dependent  conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The  implementation-dependent  characteristics 
of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to  compiler  documentation  and  not  to 
this  report.  Implementation-specific  portions  of  the  package  STANDARD,  which  are  not  a  part  of 
Appendix  F,  are: 


package  STANDARD  is 

type  INTEGER  is  range  -2**15  ..  (2**15)-1; 
type  LONGJNTEGER  is  range  -2**31  ..  (2**31)-1; 

type  FLOAT  is  digits  6  range  -(2**128  -  2**106)  ..  (2**128  -  2**106); 
type  LONG_FLOAT  is  digits  9  range  -(2**128  -  2**96)  ..  (2**128  -  2**96); 

type  DURATION  is  delta  1.0E-4  range  -131072.0000  ..  131071.9999; 

end  STANDARD; 
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Appendix  F 

Implementation-Dependent 

Characteristics 


NOTE 

This  appendix  is  not  part  of  the  standard  definition  of  the 
Ada  programming  language. 

This  appendix  summarizes  the  following  implementation-dependent 
characteristics  of  XD  Ada: 

•  Listing  the  XD  Ada  pragmas  and  attributes. 

•  Giving  the  specification  of  the  package  SYSTEM. 

•  Presenting  the  restrictions  on  representation  clauses  and  unchecked 
type  conversions. 

•  Giving  the  conventions  for  names  denoting  implementation- 
dependent  components  in  record  representation  clauses. 

•  Giving  the  interpretation  of  expressions  in  address  clauses. 

•  Presenting  the  implementation-dependent  characteristics  of  the 
input-output  packages. 

•  Presenting  other  implementation-dependent  characteristics. 


Implementation-Dependent  Characteristics  F-i 


F.1  Implementation-Dependent  Pragmas 


XD  Ada  provides  the  following  pragmas,  which  are  defined  elsewhere 
in  the  text.  In  addition,  XD  Ada  restricts  the  predefined  language 
pragmas  INLINE  and  INTERFACE,  provides  pragma  VOLATILE  in 
addition  to  pragma  SHARED,  and  provides  pragma  SUPPRESS.ALL  in 
addition  to  pragma  SUPPRESS.  See  Annex  B  for  a  descriptive  pragma 
summary. 

•  CALL.SEQUENCE.FUNCTION  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCTION  (see  Section  13.9a.l.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.l.2) 

•  IMPORT.EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT-FUNCTION  (see  Section  13.9a.l.l) 

•  IMPORT. OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13.9a.l.l) 

•  LEVEL  (see  Section  13.5.1) 

•  UNK.OPTION  (see  Annex  B) 

•  SUPPRESS. ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  VOLATILE  (see  Section  9.11) 


F.2  Implementation-Dependent  Attributes 

XD  Ada  provides  the  following  attributes,  which  are  defined  elsewhere 
in  the  text.  See  Appendix  A  for  a  descriptive  attribute  summary. 

•  BIT  (see  Section  13.7.2) 

•  MACHINE.SIZE  (see  Section  13.7.2) 

•  TYPE.CLASS  (see  Section  13.7a.2) 


F-2  Implementation-Dependent  Characteristics 


F.3  Specification  of  the  Package  System 

The  package  SYSTEM  for  the  MIL*STD-1750A  is  as  follows: 


F.3.1  Package  System  for  the  MIL-STD-1750A  Target 

package  SYSTEM  la 

type  NAME  la  (MIL_STD_1750A) ; 

SYSTEM_NAME  I  eeaatant  NAME  I-  MIL_STD_1750A; 

STORAGB_UN I T  I  constant  i-  16; 

MEMORY_SIZE  I  conatant  i-  2**17; 

MIN_INT  i  conatant  i-  -(2**31); 

MAX_INT  t  conatant  i »  2**3 1— 1 ; 

MAX~DIGITS  i  conatant  9; 

max” MANTISSA  i  conatant  i -  31; 

FlNi_DELTA  i  conatant  i-  2.0** (-31); 

TICK-  i  conatant  i«  100.0E-6; 

subtype  PRIORITY  la  INTEGER  rang*  0  ..  15; 

subtype  LEVEL  la  INTEGER  range  0  . .  7 ; 

—  Addreaa  type 

typo  ADDRESS  la  private; 

ADDRESS  ZERO  i  conatant  ADDRESS; 
type  ADDRE5S_ I NT  la  range  -32768  ..  32767; 

(unction  TO_ADDRESS  (X  i  ADDRESS_INT) 

(unction  TO~ADDRESS  (X  i  (universal_integer ) ) 

(unction  TO~ADDRESS_INT  (X  I  ADDRESS) 

(unction  "+"  (LEFT  l  ADDRESS;  RIGHT  I  ADDRESS_INT)  return  ADDRESS; 

(unction  '*+*  (LEFT  :  ADDRESS_INT;  RIGHT  I  ADDRESSj  return  ADDRESS; 

(unction  *-*  (LEFT  I  ADDRESS”  RIGHT  I  ADDRESS)  return  ADDRESS_INT; 

(unction  (LEFT  J  ADDRESS;  RIGHT  i  ADDRESS_INT)  return  ADDRESS; 

_  (unction  "**  (LEFT,  RIGHT  i  ADDRESS)  return  BOOLEAN; 

_  (unction  (LEFT,  RIGHT  t  ADDRESS)  return  BOOLEAN; 

(unction  *<"  (LEFT,  RIGHT  t  ADDRESS)  return  BOOLEAN; 

(unction  (LEFT,  RIGHT  I  ADDRESS)  return  BOOLEAN; 

(unction  ’>■  (LEFT,  RIGHT  i  ADDRESS)  return  BOOLEAN; 

(unction  ">■»"  (LEFT,  RIGHT  i  ADDRESS)  return  BOOLEAN; 

—  Note  that  because  ADDRESS  is  a  private  type 

—  the  functions  *■•  and  "/-*  are  already  available 


return  ADDRESS; 
return  ADDRESS; 
return  ADDRESS  INT; 


Implementation-Dependent  Characteristics  F-3 


Generic  function*  used  to  access  memory 

geaerie 

type  TARGET  is  private; 

fuaetioa  FETCH. FROM. ADDRESS  (A  :  ADDRESS)  retura  TARGET; 
geaerie 

type  TARGET  is  private; 

procedure  ASSIGN.TO.ADDRESS  (A  t  ADDRESS;  T  t  TARGET); 
type  TYPE.CLASS  is  (TYPE.CLASS.BNUMERATION, 

typeIclass'intbger, 

TYPE.CLASS.FIXED.POINT, 

TYPE.CLASS  FLOATING  POINT, 
TYPE_CIASS_  ARRAY, 

typb'class^rbcord, 

typeIclass“access, 

type.class'task, 

TYPb”clASS~ADDR8SS ) ; 


XD  Ada  hardware-oriented  types  and  functions 


type  BIT  ARRAY  is  array  (INTEGER  raage  <>)  of  BOOLEAN; 
pragaa  PACK( BIT_ARRAY ) ; 

subtype  8IT.ARRAY.16  is  BIT.ARRAY  (0  ..  15); 
subtype  BIT~ARRAYl32  ia  B I T^ ARRAY  (0  ..  31); 

type  UNSIGNED  WORD  is  raage  0  ..  65535; 
for  unsigned" WORD' SIZE  use  16; 


fuaetioa  "not"  (LEFT 
fuaetioa  -and-  (LEFT 
fuaetioa  "or*  (LEFT 
fuaetioa  "xor*  (LEFT 


l  UNSIGNED  WORD) 
RIGHT  J  UNSIGNED* WORD) 
RIGHT  t  UNSIGNED* WORD) 
RIGHT  l  UNSIGNED" WORD) 


retura  UNS I GNED_WORD  t 
retura  UNS1GNED~W0RD; 
retura  UNSIGNED~WORD; 
retura  UNSIGNED~word; 


fuaetioa  TO  UNSIGNED. WORD  (X  t  BIT  ARRAY  16)  retura  UNSIGNED  WORD; 
fuaetioa  TO~ BIT. ARRAY. 16  (X  I  UNSIGNED.WORD)  retura  BIT_ARRAY~16 ; 


type  UNSIGNED_WORD_ARRAY  is  array  (INTEGER  raage  <>)  of  UNSIGNED. WORD; 


type  UNS I GNED.LONGWORD  is  raage  MIN.INT  ..  MAX. I NT; 

for  UNSIGNED.WORD' SIZE  use  32; 


fuaetioa  "not"  (LEFT  «  UNS IGNED.LONGWORD )  retura  UNSIGNED.LONGWORD; 

fuaetioa  "and"  (LEFT,  RIGHT  s  UNSIGNED.LONGWORD)  retura  UNS I GNED~LONGWORD ; 

fuaetioa  "or"  (LEFT,  RIGHT  i  UNSIGNED.LONGWORD)  retura  UNSIGNED^LONGWORD; 

fuaetioa  “xor"  (LEFT,  RIGHT  I  UNSIGNED.LONGWORD)  retura  UNS I GNED~LONGWORD ; 

fuaetioa  TO.UNS IGNED.LONGWORD  (X  I  BIT.ARRAY.32 )  retura  UNSIGNED.LONGWORD; 

fuaetioa  TO.BIT_ARRAY.32  (X  »  UNSIGNED.WORD)  retura  BIT.ARRAY.32; 

type  UNSIGNED.LONGWORD. ARRAY  is  array  (INTEGER  raage  <>)  of  UNSIGNED.LONGWORD; 
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Conventional  names  for 

subtype  UNSIGNED. 1  is 
subtype  UNSIGNED.2  is 
subtype  UNSIGNED.3  is 
subtype  UNSIGNED. 4  is 
subtype  UNSIGNBD.5  is 
subtype  UNSIGNBD.6  is 
subtype  UNSIGNED.7  is 
subtype  UNSIGNED. 8  is 
subtype  UNSIGNED.9  is 
subtype  UNSIGNED- 10  is 
subtype  UNSIGNBD.il  is 
subtype  UNSIGNED. 12  is 
subtype  UNSIGNED^  is 
subtype  UNSIGNED.14  is 
subtype  UNSIGNED- IS  is 
subtype  UNSIGNED. 16  is 
subtype  UNSIGNED~17  is 
subtype  UNSIGNED~18  is 
subtype  UNSIGNED. 19  is 
subtype  UNSIGNED~20  is 
subtype  UNSIGNBD.21  is 
subtype  UNSIGNED.22  is 
subtype  UNSIGNED.23  is 
subtype  UNSIGNBD.24  is 
subtype  UNSIGNED.2S  is 
subtype  UNSIGNBD.26  is 
subtype  UNSIGNED  27  is 
subtype  UNSIGNED.28  is 
subtype  UNSIGNBD.29  is 
subtype  UNSIGNED.30  is 
subtype  UNSIGNED  31  is 


static  subtypes  of  type 

UNSIGNED.LONGWORD  reaps 
UNSIGNED.LONGWORD  range 
UNSIGNEdZlonGWORD  reage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNEDlLONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED  LONGWORD  reage 
UNSIGNED.LONGWORD  reage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED- LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED.LONGWORD  raage 
UNSIGNED  LONGWORD  raage 


private 

—  Not  shown 
sad  SYSTEM; 


UNSIGNED.LONGWORD 

0  ..  2**  1-1; 

0  ..  2*«  2-1; 

0  ..  2**  3-1; 

0  ..  2*»  4-1; 

0  ..  2**  5-1 j 
0  . •  2**  6-1; 

0  ..  2*«  7-1; 

0  ..  2**  8-1; 

0  ..  2«*  9-1; 

0  ..  2** 10-1; 

0  ..  2** 11-1; 

0  ..  2** 12-1 ; 

0  ..  2»*13-1; 

0  ..  2**14- 1 ; 

0  ..  2**1 5— 1 } 

0  ..  2*»16-1; 

0  ..  2** 17  —  1 ; 

0  ..  2»* 18— 1 ; 

0  ..  2**19-1; 

0  ..  2  *  *  20— 1 ; 

0  ..  2**2 1— 1 ; 

0  ..  2**22— 1 ; 

0  ..  2**23-l; 

0  ..  2**24-l; 

0  ..  2*»25-l; 

0  ..  2**26-l ; 

0  ..  2«*27-l; 

0  ..  2**2B-1; 

0  ..  2**29- 1 ; 

0  ..  2**30-l; 

0  ..  2**31-1; 


F.4  Restrictions  on  Representation  Clauses 


The  representation  clauses  allowed  in  XD  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 
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F.5  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

XD  Ada  does  not  allocate  implementation-dependent  components  in 
records. 


F.6  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
defined  in  package  SYSTEM  (see  Section  13.7a.l  and  Section  F.3). 

XD  Ada  allows  address  clauses  for  variables  (see  Section  13.5).  For 
address  clauses  on  variables,  the  address  expression  is  interpreted  as  a 
MIL-STD-1750A  16-bit  logical  address. 

XD  Ada  supports  address  clauses  on  task  entries  to  allow  interrupts  to 
cause  a  reschedule  directly.  For  address  clauses  on  task  entries,  the 
address  expression  is  interpreted  as  a  MIL-STD-1750A  interrupt  number 
in  the  range  0  ..  15. 

In  XD  Ada  for  MIL-STD-1750A,  values  of  type  SYSTEM. ADDRESS  are 
interpreted  as  integers  in  the  range  -215  ..  2 15  -1.  As  SYSTEM.ADDRESS 
is  a  private  type,  the  only  operations  allowed  on  objects  of  this  type  are 
those  given  in  package  SYSTEM. 


F.7  Restrictions  on  Unchecked  Type  Conversions 

XD  Ada  supports  the  generic  function  UNCHECKED.CONVERSION 
with  the  restrictions  given  in  Section  13.10.2. 
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F.8  Implementation-Dependent  Characteristics  of 
Input-Output  Packages 

The  packages  SEQUENTIAL. IO  and  DIRECT _IO  are  implemented  as 
null  packages  that  conform  to  the  specification  given  in  the  Reference 
Manual  for  the  Ada  Programming  Language.  The  packages  raise  the  ex¬ 
ceptions  specified  in  Chapter  14  of  the  Reference  Manual  for  the  Ada 
Programming  Language.  The  three  possible  exceptions  that  are  raised  by 
these  packages  are  given  here,  in  the  order  in  which  they  are  raised. 


Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  tu  operate  upon  or  dose  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

USE.ERROR 

Raised  if  exception  STATUS.ERROR  is  not  raised. 

MODE.ERROR  cannot  be  raised  since  no  file  can  be  opened  (therefore 
it  cannot  have  a  current  mode). 

The  predefined  package  LOW.LEVEL.IO  is  provided. 


F.8.1  The  Package  TEXT  JO 

The  package  TEXTJO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  String  input- 
output  is  implemented  as  defined.  Pile  input-output  is  supported  to 
STAND  ARD.INPUT  and  ST  AND  ARD.OUTPUT  only.  The  possible 
exceptions  that  are  raised  by  package  TEXTJO  are  as  follows: 
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Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  dose  a  file 
that  is  not  open  (no  files  can  be  optned). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

MODE.ERROR 

Raised  by  an  attempt  to  read  from,  or  test  for 
the  end  of,  STANDARD.OUTPUT,  or  to  write  to 
STANDARD.  INPUT. 

END.ERROR 

Raised  by  an  attempt  to  read  past  the  end  of 
STANDARD.1NPUT. 

USE.ERROR 

Raised  when  an  unsupported  operation  is  attempted, 
that  would  otherwise  be  legal. 

The  type  COUNT  is  defined  as  follows: 

typ*  COUNT  i •  ru|!  0  ..  INTEGER' LAST; 

The  subtype  FIELD  is  defined  as  follows: 

typ*  FIELD  la  INTEGER  ruga  0  ..  132; 


F.8.2  The  Package  IO_EXCEPTIONS 

The  specification  of  the  package  IO.EXCEPTIONS  is  the  same  as  that 
given  in  the  Reference  Manual  for  the  Ada  Programming  Language. 


F.9  Other  Implementation  Characteristics 

Implementation  characteristics  associated  with  the  definition  of  a  main 
program,  various  numeric  ranges,  and  implementation  limits  are  sum¬ 
marized  in  the  following  sections. 


F.9.1  Definition  of  a  Main  Program 

Any  library  procedure  can  be  used  as  a  main  program  provided  that  it 
has  no  formal  parameters. 
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The  ranges  of  values  for  integer  types  declared 
are  as  follows: 


in  package  STANDARD 


INTEGER 

LONGJNTEGER 


-2,s  ..  2’5  -1 

-231  ..  231  -1 


(  -32768  ..  32767) 

(-2147483648  ..  2147483647) 


n?rr«e  P4ckafe '  TEXT_IO,  the  range  of  values  for  types  COUNT  and 
FIELD  are  as  follows: 

COUNT  0  ..  2IS  -1  (0  ..  32767) 

FIELD  0  ..  132 


F.fl.3  Valuta  of  Floating-Point  Attributes 

Floating-point  types  are  described  in  Section  3.5.7.  The  representation 
attributes  of  floating-point  types  are  summarized  in  the  following  table: 
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FLOAT 

LONG.FLOAT 

DIGITS 

6 

9 

SIZE 

32 

48 

MANTISSA 

21 

31 

EMAX 

84 

124 

EPSILON 

2~20 

2 -30 

SMALL 

2~85 

2~ 125 

LARGE 

2*4  _2« 

2124  _2»3 

SAFE.EMAX 

127 

127 

SAFE.SMALL 

2"  126 

2—126 

SAFE.LARGE 

2l27_2'<>6 

2127  _2% 

FIRST 

^(2^28^ 2^®®j 

-(2128-296) 

LAST 

2l28_2lO» 

2128^2®® 

MACHINE.RADIX 

2 

2 

MACHINE.MANTISSA 

23 

39 

MACHINE.EMAX 

127 

127 

MACHINE.EMIN 

-128 

128 

MACHINE.ROUNDS 

FALSE 

FALSE 

MACHINE_OVERFLOWS 

FALSE 

FALSE 
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F.9.4  Attributes  of  Type  DURATION 

The  values  of  the  significant  attributes  of  type  DURATION  are  as 
follows: 

DURATION 'DELTA  l.E-4  (1(T4) 

DURATION 'SMALL  2#1.0#E-14  (2“14) 

DURATION 'FIRST  -131072.0000  (-217) 

DURATION '  LAST  131071.9999  (2‘7- 'DELTA) 

F.9.5  Implementation  Limits 

Limit  Descript1,  n 

255  Maximuir.  identifier  length  (number  of  characters) 

255  Maximum  number  of  characters  in  a  source  line 

210  Maximum  number  of  library  units  and  subunits  in  a  compilation 

closure1 

21Z  Maximum  number  of  library  units  and  subunits  in  an  execution 

closure2 

215  -1  Maximum  number  of  enumeration  literals  in  an  enumeration 

type  definition 

216  -1  Maximum  number  of  lines  in  a  source  file 

215  x  16  Maximum  number  of  bits  in  any  object 

2“  -1  Maximum  number  ci  exceptions 

*The  compilation  closure  of  a  given  unit  is  the  total  set  of  units  that  the  given  unit 
depends  on,  directly  and  indirectly. 

zThe  execution  closure  of  a  given  unit  is  the  compilation  closure  plus  all  associated 
secondary  units. 
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Appendix  F 

Implementation-Dependent 

Characteristics 


This  appendix  describes  Version  1.2  additions  to  the  range  of 
implementation-dependent  pragmas. 


F.1  Implementation-Dependent  Pragmas 

XD  Ada  MIL-STD-1750A  Version  1.2  supplies  three  new  pragmas, 
DIRECT _INTERRUPT_ENTRY,  IDENT  and  TIME.SLICE.  In  the  follow¬ 
ing  full  list  of  supported  pragmas,  references  refer  to  sections  in  the 
XD  Ada  MIL-STD-1750A  Supplement  to  the  Ada  Language  Reference  Manual, 
unless  updated  by  sections  supplied  in  this  manual. 

•  CALL_SEQUENCE_FUNCTION  (see  Annex  B) 

•  CALL_SEQUENCE_PROCEDURE  (see  Annex  B) 

•  DIRECTJNTERRUPT.ENTRY  (see  Section  13.5.1) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCTION  (see  Section  13.9a.l.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.l.2) 

•  IDENT  (see  Annex  B) 

•  IMPORT.EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCTION  (see  Section  13.9a. 1.1) 

•  IMPORT_OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13.9a. 1.1) 
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•  LEVEL  (see  Section  13.5.1) 

•  UNK.OPTION  (see  Annex  B) 

•  SUPPRESS. ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  TIME.SLICE  (see  Section  9.8a) 

•  VOLATILE  (see  Section  9.11) 


F-2  Implementation-Dependent  Characteristics 


Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


Supplementary  XD  Ada  information  is  provided  for  Sections  13.1,  13.2, 
13.3,  13.4,  13.5,  13.5.1,  13.7,  13.7.1,  13.7.2,  13.7.3,  13.8,  13.9,  13.10.1 
and  13.10.2.  Two  additional  sections,  Section  13.7a  and  Section  13.9a, 
provide  XD  Ada  information  on  the  package  SYSTEM  and  on  the  XD 
Ada  import  and  export  pragmas. 


13.1  Representation  Clauses 

The  following  information  supplements  paragraphs  4  and  8: 

In  XD  Ada,  an  address  clause  can  only  apply  to  a  variable  or  a  single 
entry;  an  address  clause  cannot  apply  to  a  constant,  subprogram, 
package,  or  task  unit.  See  Section  13.5  for  further  explanation. 

The  following  information  supplements  paragraph  13: 

Pragma  PACK  is  implemented  in  XD  Ada.  As  the  behavior  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada,  all  array  and  record  components  are  aligned  on  word 
boundaries  by  default;  the  effect  of  pragma  PACK  on  a  record  or 
array  is  to  cause  those  components  that  are  packable  to  be  allocated  in 
adjacent  bits  without  regard  to  word  boundaries.  Whether  any  particular 
component  is  packable  depends  on  the  rules  for  its  type;  the  XD  Ada 
MIL-STD-1750A  Run-Time  Reference  Manual  gives  information  on  which 
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types  can  be  packed  as  components  of  composite  types,  as  well  as 
information  on  how  these  types  are  packed. 

A  record  component  that  begins  a  variant  is  always  allocated  at  the  next 
word  boundary;  a  variant  that  begins  on  other  than  a  word  boundary 
can  be  obtained  only  with  a  record  representation  clause. 

XD  Ada  provides  no  additional  representation  pragmas. 

The  following  information  supplements  paragraph  14: 

XD  Ada  does  not  allow  a  representation  clause  for  a  type  that  depends 
on  a  generic  formal  type.  A  type  depends  on  a  generic  formal  type 
if  it  has  a  subcomponent  of  a  generic  formal  type  or  a  subcomponent 
that  depends  on  a  generic  formal  type,  or  if  it  is  derived  from  a  generic 
formal  type  or  a  type  that  depends  on  a  generic  formal  type. 


13.2  Length  Clauses 

The  following  information  supplements  paragraph  6: 

In  XD  Ada,  for  a  discrete  type,  the  given  size  must  not  exceed  32 
(bits).  The  given  size  becomes  the  default  allocation  for  all  objects  and 
components  (in  arrays  and  records)  of  that  type.  However,  sizes  of 
objects  may  be  increased  by  the  compiler  for  optimization  purposes. 

For  integer  and  enumeration  types,  the  given  size  affects  the  internal 
representation  as  follows:  for  integer  types,  high  order  bits  are  sign- 
extended;  for  enumeration  types,  the  high  order  bits  may  be  either 
zero-  or  sign-extended  depending  upon  the  base  representation  that 
is  selected.  For  all  other  types,  the  given  size  must  equal  the  size  that 
would  apply  in  the  absence  of  a  size  specification. 

The  following  information  supplements  paragraph  8: 

The  specification  of  a  collection  size  is  interpreted  as  follows.  If  the 
value  of  the  expression  is  greater  than  or  equal  to  zero,  the  specified 
size  is  then  used  as  the  initial  size  of  the  collection;  the  collection  is  not 
extended  should  that  initial  allocation  be  exhausted.  In  the  absence  of 
a  T'STORAGE_SIZE,  no  storage  is  initially  allocated  for  the  collection; 
storage  is  allocated  from  the  heap  as  needed,  until  all  heap  memory  is 
exhausted.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT. 
ERROR  is  raised. 

The  following  information  supplements  paragraph  10: 

A  task  storage  specification  overrides  the  default  task  storage  size.  The 
specification  is  interpreted  as  follows.  If  the  value  of  the  expression  is 
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greater  than  zero,  the  specified  size  determines  the  number  of  storage 
units  (words)  to  be  allocated  for  an  activation  of  the  task  of  the  given 
type.  In  the  absence  of  a  T'STORAGE_SIZE,  a  default  allocation  is 
used.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT, 
ERROR  is  raised. 

The  following  information  supplements  paragraphs  8  and  10: 

NOTE 

The  XD  Ada  M1L-STD-1750A  Run-Time  Reference  Manual  dis¬ 
cusses  task  and  access  type  storage  and  storage  allocation  in 
more  detail. 

The  following  information  supplements  paragraph  12: 

Arbitrary  values  of  small  are  not  accepted. 


13.3  Enumeration  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

In  XD  Ada,  the  only  specific  restriction  on  enumeration  representation 
clauses  is  that  each  expression  for  an  integer  code  must  have  a  value  in 
the  range  MIN.INT  ..  MAXJNT. 


13.4  Record  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

For  statically  allocated  objects  and  for  objects  allocated  from  a  collection 
in  XD  Ada,  the  simple  expression  in  an  alignment  clause  must  be  a 
power  of  two.  The  upper  limit  is  216.  The  alignment  then  occurs  at 
a  location  that  is  a  number  of  words  times  the  val"**  of  the  simple 
expression:  a  value  of  1  causes  word  alignment,  a  value  of  2  causes 
longword  alignment,  and  so  on. 

Further  restrictions  apply  for  objects  declared  within  a  subprogram, 
where  XD  Ada  restricts  the  alignment  to  mod  1.  In  other  words,  stack- 
allocated  objects  can  only  be  word  aligned. 

Bit-alignable  representation  clauses  are  provided  for  discrete  types, 
arrays  of  discrete  types,  and  record  types. 

See  the  XD  Ada  MIL-STD-1750A  Run-Time  Reference  Manual  for  informa¬ 
tion  on  how  objects  are  allocated. 
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The  following  information  supplements  paragraph  5: 

A  component  clause  specifies  the  storage  place  of  a  component  relative  to 
the  start  of  the  record.  In  XD  Ada  for  MIL-STD-1750A  targets,  the  size 
of  a  storage  unit  (SYSTEM.  STORAGE.UNIT)  is  16  bits  (one  word).  If 
the  number  of  bits  specified  by  the  range  is  sufficient  for  the  component 
subtype,  the  requested  size  and  placement  of  the  field  is  observed  (and 
overlaps  storage  boundaries  if  necessary);  otherwise,  the  specification  is 
illegal.  For  a  component  of  a  discrete  type,  the  number  of  bits  must  not 
exceed  32;  for  a  component  of  any  other  type,  the  size  must  not  exceed 
the  actual  size  of  the  component.  See  the  XD  Ada  MIL-STD-1750A  Run¬ 
Time  Reference  Manual  for  information  about  determining  the  number  of 
bits  that  are  sufficient  for  any  given  subtype. 

Component  values  in  XD  Ada  are  biased  when  a  component  clause 
requires  a  very  small  component  storage  space;  each  value  stored 
is  the  unsigned  quantity  formed  by  subtracting  COMPONENT. 
SUBTYPE 'FIRST  from  the  original  value.  See  the  XD  Ada  MIL-STD- 
1750A  Run-Time  Reference  Manual  for  more  detailed  information. 

Component  clauses  in  XD  Ada  are  restricted  as  follows.  Any  com¬ 
ponent  that  is  not  packable  must  be  allocated  on  a  word  boundary. 
Components  that  are  packable  can  be  allocated  without  restriction.  See 
the  XD  Ada  M1L-STD-1750A  Run-Time  Reference  Manual  for  a  definition 
and  description  of  packable  components. 

The  following  information  supplements  paragraph  6: 

Components  named  in  a  component  clause  are  allocated  first;  then, 
unnamed  components  are  allocated  in  the  order  in  which  they  are 
written  in  the  record  type  declaration.  Variants  can  be  overlapped.  If 
pragma  PACK  is  specified,  packed  allocation  rules  (see  Section  13.1) 
are  used;  otherwise,  unpacked  allocation  is  used. 

The  following  information  supplements  paragraph  8: 

XD  Ada  generates  no  implementation-dependent  components  or 
names. 

The  following  information  supplements  the  Notes  section: 

The  example  of  record  representation  and  address  clauses  in  the 
Reference  Manual  for  the  Ada  Programming  Language  is  not  relevant  lor 
XD  Ada  as  it  assumes  that  type  ADDRESS  is  represented  in  24  bits, 
whereas  in  XD  Ada  type  ADDRESS  is  represented  in  16  bits.  The 
following  example  is  appropriate  to  XD  Ada; 
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Example: 

type  CONDITION_CODE  is  (C,P,Z,N); 

type  COND I T I 0N_C0D8S  is  array  (CONDITION_CODB)  of  BOOLEAN ; 
pragma  PACK  (CONDITION_CODES) ; 

typa  PROGRAM_STATUS_WORD  ia 
reeord 

CS  t  CONDITION_CODES 

RESERVED  i  INTEGER  rang*  0  ..  15; 

PS  t  INTEGER  raaga  0  ..  15; 

AS  t  INTEGER  raaga  0  ..  15; 

and  raeord; 

far  PROGRAM_STATUS_WORD  uaa 
raeord  at  mod  1; 

CS  at  0  raaga  0  . .  3 ; 

RESERVED  at  0  raaga  4  ..  7; 

PS  at  0  raaga  8  ..11; 

AS  at  0  raaga  12  ..  15; 

aad  raeord) 

for  PROG RAM_STATUS_WORD' SIZE  uao  1  •  SYSTEM. STORAGE_UNIT; 

Note  on  the  exemple: 

The  record  representation  clause  defines  the  record  layout.  The  length 
clause  guarantees  that  exactly  one  storage  unit  is  used. 

Component  Specification  Example: 

aubtypo  S  is  INTEGER  raago  10  ..  13; 

typo  REC  ia 
raeord 
X  i  S; 

Y  t  S; 
aad  raeord; 

for  REC  uaa 
raeord 

X  at  0  raaga  0  ..  3;  —  legal  because  4  bits 

—  are  sufficient 

Y  at  0  raaga  4  ..  4;  —  illegal  because  1  bit  is 

—  not  enough  to  represent 

—  an  integer  of  subtype  S 

ead  record; 


13.4  Record  Representation  Clauses 
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Notts  on  ths  sxsmpls: 

The  subtype  declaration  in  this  example  implies  an  integer  with  a  min¬ 
imum  size  of  four  bits.  However,  the  components  X  and  Y  of  subtype 
S  are  biased  and  can  be  stored  in  only  two  bits.  The  component  clause 
for  X  is  legal  because  it  requires  at  least  the  minimum  number  of  bits 
required  for  the  integer  subtype;  the  component  clause  for  Y  is  illegal 
because  it  does  not  allow  enough  bits  to  represent  the  integer  subtype. 


13.5  Address  Clauses 

The  following  information  supplements  paragraph  7; 

Like  VAX  Ada,  XD  Ada  supports  address  clauses. 

In  XO  Ada,  the  simple  name  must  be  the  name  of  a  variable.  XD  Ada 
does  not  allow  address  clauses  that  name  constants;  or  subprogram, 
package,  or  task  units. 

An  intermediate  pointer  is  created  only  if  the  resulting  address  is  not  a 
compile-time  constant. 

The  placement  of  an  address  clause  in  XD  Ada  must  follow  the  rules 
given  in  Section  13.1.  In  other  words,  the  clause  and  the  variable 
declaration  must  both  occur  immediately  within  the  same  declarative 
part  or  package  specification,  and  the  declaration  must  occur  before 
the  clause.  The  restrictions  for  forcing  occurrences  also  apply;  with 
respect  to  address  clauses,  any  occurrence  of  the  variable  name  after  its 
declaration  is  a  forcing  occurrence. 

Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored. 

The  following  information  supplements  the  Notes  section: 

Also,  if  an  address  clause  is  specified  for  an  object  of  a  type  that  has 
been  declared  with  an  alignment  clause,  the  alignment  required  for  the 
address  is  checked  against  the  alignment  given  for  the  record  type.  If 
the  two  are  incompatible,  the  exception  PROGRAM_ERROR  is  raised. 

The  same  check  applies  to  a  type  that  contains  a  component  of  a  type 
that  has  been  declared  with  an  alignment  clause  (the  alignment  of  the 
component  forces  the  alignment  o:  the  containing  type). 
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Address  Clauses  13.5 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  1750A  interrupt  number. 

XD  Ada  provides  the  additional  pragma  LEVEL.  This  pragma  is  given 
for  a  task  type,  or  single  task  of  anonymous  type,  and  gives  the  level  for 
its  interrupts. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MIL-STD • 
1750A  Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  run  at  interrupt  level  whilst 
accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of  the  same 
level  or  lower  levels  are  inhibited.  It  is  possible  to  lose  interrupts  with 
this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  behaves  like  an  ordinary 
entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  behaves  like  a 
conditional  entry  call.  If  there  is  an  accept  statement  waiting  for  the 
interrupt,  the  body  of  the  accept  statement  is  executed  immediately. 
When  the  body  is  complete,  the  task  is  inserted  in  the  ready  queue 
and  the  interrupt  completed  by  a  retum-from-interrupt  instruction.  The 
accept  statement  can  make  excursions  into  other  routines,  and  can  even 
make  entry  calls,  but  must  not  suspend  the  task  before  the  interrupt 
is  dismissed,  otherwise  the  program  repeatedly  services  the  interrupt 
unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 


13.5.1  Interrupts 


13-7 


13.7  The  Package  System 


The  following  information  supplements  paragraph  1: 

XD  Ada  additions  to  the  package  SYSTEM  are  described  in  Section 
13.7a. 

The  following  information  supplements  paragraph  3: 

Addresses  are  treated  as  16-bit  logical  addresses  as  represented  on 
the  target  in  a  register  or  memory  location.  The  physical  address  is 
determined  by  the  page  registers  and  the  address  state. 

The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  enumeration  literal  for  SYSTEM_NAME  is  MIL-STD- 
1750 A. 

The  following  information  supplements  paragraph  7: 

In  XD  Ada,  the  value  given  for  STORAGE_UNIT  must  be  16  (bits). 

The  following  information  supplements  paragraph  9: 

In  XD  Ada,  the  number  given  for  MEMORY_SIZE  must  be  131072.  Like 
VAX  Ada,  XD  Ada  does  not  provide  support  for  checking  or  ensuring 
that  the  given  size  is  not  exceeded. 

The  following  information  supplements  paragraph  11: 

As  with  VAX  Ada,  XD  Ada  imposes  no  further  limitations  on  these 
pragmas.  To  reduce  the  amount  of  recompilation  required,  XD  Ada 
identifies  those  units  that  have  a  real  dependence  on  the  values  affected 
by  these  pragmas;  only  such  units  must  be  recompiled.  In  particular, 
predefined  XD  Ada  packages  do  not  depend  on  the  values  affected  by 
these  pragmas,  and  none  require  recompilation  if  these  pragmas  are 
used. 


1 3.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

In  addition  to  the  language-required  declarations  in  package  SYSTEM, 
XD  Ada  declares  the  operations,  constants,  types,  and  subtypes  de¬ 
scribed  in  the  following  sections. 
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XD  Ada  Additions  to  ue  Package  SYSTEM  13.7a 


13.7a.1  Propartita  of  tha  Tvoa  ADDRESS 

In  XD  Ada,  ADDRESS  is  a  private  type  for  which  the  following  opera¬ 
tions  are  declared: 

—  Address  type 

type  ADDRESS  le  private; 

ADDRBSS_ZkRO  t  eeastest  ADDRESS) 

type  ADDRBSS.INT  is  rea«e  -32768  ..  32767) 

fuaetlea  TO_ADDRSSS  (X  i  ADDRESS_INT)  retura  ADDRESS) 

feaetiea  TO_ADDRESS  (X  t  (universsl_integer } )  retura  ADDRESS) 

(uaetlea  TO_ADDRBSS_ I NT  (X  l  ADDRESS)  retura  ADDRESS_INT) 

fuaetlea  *«•"  (LEFT  «  ADDRESS)  RIGHT  »  ADDRESS  I NT)  retura  ADDRESS; 

fuaetlea  "♦*  (LEFT  «  ADDRESS_INT)  RIGHT  l  ADDRESS*  retura  ADDRESS) 

fuaetlea  (LEFT  i  ADDRESS;  RIGHT  t  ADDRESS)  retura  ADDRESS  INT; 

fuaetlea  (LEFT  l  ADDRESS;  RIGHT  l  ADDRESS_INT)  retura  ADDRESS! 

—  fuaetlea  (LEFT,  RIGHT  t  ADDRESS)  retura  BOOLEAN) 

—  fuaetlea  */-"  (LEFT,  RIGHT  i  ADDRESS)  retura  BOOLEAN) 

fuaetlea  "<"  (LEFT,  RIGHT  i  ADDRESS)  retura  BOOLEAN; 

fuaetlea  (LEFT,  RIGHT  i  ADDRESS)  retura  BOOLEAN; 

fuaetlea  ">"  (LEFT,  RIGHT  i  ADDRESS)  retura  BOOLEAN; 

fuaetlea  ">-*  (LEFT,  RIGHT  t  ADDRESS)  retura  BOOLEAN; 

—  Note  that  becauae  ADDRESS  la  a  private  type 

—  the  functione  "■*  and  */-*  are  already  available 

—  Generic  functione  uaed  to  acceaa  memory 

yeaarle 

type  TARGET  la  private; 

fuaetlea  FBTCH_FROM_ ADDRESS  (A  <  ADDRESS)  retura  TARGET; 

yeaeric 

type  TARGET  la  private; 

procedure  ASSIGN JTO_ADDRESS  (A  I  ADDRESS)  T  I  TARGET); 

The  addition,  subtraction,  and  relational  functions  provide  arithmetic 
and  comparative  operations  for  addresses.  The  generic  subprograms 
FETCHJFROM.ADDRESS  and  ASSIGN.TO.ADDRESS  provide  op¬ 
erations  for  reading  from  or  writing  to  a  given  address  interpreted  as 
having  any  desired  type.  ADDRESS_ZERO  is  a  deferred  constant  whose 
value  corresponds  to  the  first  (machine)  address. 


Properties  of  the  Type  ADDRESS  I3.7a.1 
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In  an  instantiation  of  FETCH_FROM_ADDRESS  or  ASSIGN.TO. 
ADDRESS,  the  actual  subtype  corresponding  to  the  formal  type  T 
must  not  be  an  unconstrained  array  type  or  an  unconstrained  type  with 
discriminants.  If  the  actual  subtype  is  a  type  with  discriminants,  the 
value  fetched  by  a  call  of  a  function  resulting  from  an  instantiation  of 
FETCH.FROM.ADDRESS  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype.  In  any  other  case,  no  check 
is  made. 

Example: 

X  i  INTEGER; 

A  l  SYSTEM. ADDRESS  I-  X' ADDRESS;  —  lagal 

fuaetlaa  FETCH  la  aaw  FETCH. FROM_ ADDRESS ( INTEGER) J 
pr*«a4ttra  ASSIGN  la  aav  ASS IGNjrcf  ADDRESS ( INT2GBR) ; 

X  t-  FETCH (A) t  --  Uka  'X  «-  A. all 

ASSIGN) A, X) I  —  Ilka  "A. all  i-  X;" 


13. 7a. 2  Typ#  Class  Enumeration  Type 

XD  Ada  declares  the  following  enumeration  type  for  identifying  the 

various  Ada  type  classes: 

tyjpa  TYPE  CLASS  la  ( TYPE_CLASS_ENUME RATION , 

TYPE~CLASS~ INTEGER, 
typb"class_fixed_point, 

TYPB~CLASS  FLOATING-POINT, 
typb"class  ARRAY, 

TYPE.CLASS.RECORD , 

TYPE  CLASS  ACCESS, 

TYP8~CLASS_TASK, 

TYPB_CLASS_ADDRBSS ) } 

In  addition  to  the  usual  operations  for  discrete  types  (see  Section  3.5.3), 

XD  Ada  provides  the  attribute  TYPE.CLASS. 

For  every  type  or  subtype  T: 

T' TYPE, CLASS  Yields.the  value  of  the  type  cla  for  the  full  type  of 
T.  If  T  is  a  generic  formal  type,  then  the  value  is  that 
for  the  corresponding  actual  subtype.  The  value  of 
this  attribute  is  of  the  type  TYPE-CLASS. 

This  attribute  is  only  allowed  if  its  unit  names  the  predefined  package 

SYSTEM  in  a  with  clause. 
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I3.7a.2  Type  Class  Enumeration  Type 


Examples 

Given 


type  MY_INT  is  rang*  1..10; 
type  NEW_INT  is  saw  STRING; 
package  PACK  is 

typa  PRIV  is  private; 
privata 

typa  priv  is  saw  FLOAT; 
aad  PACK; 

then 

—  MY  INT'TYPE  CLASS  equals  TYPE  CLASS, INTEGER 

—  NEK  I NT ' TYPi_CLASS  equals  TYPb'cLASS, ARRAY 

—  PRIV'TYPE  CLASS  equals  TYPE  CLASS  FLOATING_POINT 


I3.7a.3  Hsrdwars-Oritntsd  Typta  and  Functions 

XD  Ada  declares  the  following  types,  subtypes,  and  functions  for  con¬ 
venience  in  working  with  MIL-STD-1750A  hardware-oriented  storage: 


—  XD  Ada  hardware-oriented  types  and  functions 

typa  BIT_ ARRAY  is  array  (INTEGER  range  <>)  of  BOOLEAN; 

pragae  RACK (BIT  ARRAY); 

subtype  BIT_ARRAY_16  is  BIT_ARRAY  (0  ..  1S)( 
subtype  BITJIRRAY,32  is  8 1 T_ ARRAY  (0  ..  31); 
typa  UNSIGn2d_N0RD  is  range  0  ..  65535; 
far  UNSIGNED- WORD' SIZE  use  16; 

fuaetiea  "not"  (LEFT  «  UNSIGNED,WORD)  return  UNSIGNED_WORD; 

funetlen  "and"  (LEFT,  RIGHT  i  UNSIGNED- WORD)  return  UNSIGNED_WORD; 

function  "or"  (LEFT,  RIGHT  i  UNSIGNED  j*0RD)  return  UNSIGNED, WORD; 

fuaetiea  "xor"  (LEFT,  RIGHT  i  UNSIGNED- WORD)  return  UNSIGNBD_WORD; 


function  TO_UNSIGNED_WORD  (X  J  BIT  ARRAY_I6)  return  UNSIGNED_WORD; 
function  TO-BIT_ARRAY_16  (X  i  UNSIGNED., WORD)  return  BIT_ARRAY_16; 

type  UNSIGNBD_WORD_ ARRAY  is  array  (INTEGER  range  <>)  of  UNSIGNED, WORD; 


type  UNSIGNBD_LONGWORD  is  range  MIN_INT  ..  MAX, I NT; 
far  UNSIGNBD.LONGWORD'SIZE  use  32; 


function  "not" 
function  "and" 
function  "or" 
function  "xor" 


(LEFT 

(LEFT,  RIGHT 
(LEFT,  RIGHT 
(LEFT,  RIGHT 


I  UNSIGNED_L0NGW0RD ) 
I  UNSIGNED- L0NGW0RD ) 
l  UNSIGNED-LONGWORD) 
l  UNSIGNED-L0NGW0RD) 


return  unsigned_longword; 

return  UNSIGNED~LONGWORD; 
return  UNSIGNED^LONGWORD; 
return  UNSIGNED~L0NGW0RD; 


Hardware-Oriented  Types  and  Functions  I3.7a.3 


13-11 


function  TO.UNS IGNED.LONGWORD  (X  i  BIT_ARRAY_32 )  rnturn  UNS IGNED_L0NGW0RD ; 
function  TO-BIT_ARRAY_32  (X  •  u';SIGNED-WORD)~rsturn  BIT_ARRAY_327 

typa  UNSIGNED_LONGWORD_ ARRAY  in  army  (INTEGER  rang*  <>)  of  UNSIGNBD_LONGWORD; 


13. 7a. 4  Conventional  Names  for  Unsigned  Longwords 

Tne  following  XD  Ada  declarations  provide  conventional  names  for 
static  subtypes  of  the  predefined  type  UNSIGNED. LONGWORD: 

subtypa  UNSIGNRD  1  in  UNSIGNED  LONGWORD  rang#  0  ..  2**  1-1; 
subtypa  UNSIGNED-2  is  UNSIGNED-LONGWORD  raaga  0  ..  2**  2-1; 
aubtypa  UNSIGNED-3  is  UNSIGNED-LONGWORD  raaga  0  . .  2**  3-1; 
subtypa  UNSIGNED-4  is  UNSIGNED-LONGWORD  raaga  0  ..  2**  4-1; 
subtypa  UNSIGNEP-5  is  UNSIGNED~LONGWORD  raaga  0  ..  2**  5-1; 
aubtypa  UNSIGNED-6  is  UNSIGNED-LONGWORD  raaga  0  ..  2**  6-1; 
subtypa  UNSIGNED-7  is  UNSIGNED-LONGWORD  raaga  0  ..  2**  7-1; 
aubtypa  UNSIGNED-8  *s  UNSigned-longword  raaga  0  . .  2**  8-1; 
subtypa  UNSIGNED-9  is  UNSIGNED-LONGWORD  raaga  0  . .  2**  9-1; 
subtypa  UN SIGNED- 10  is  UNSIGNED-LONGWORD  raaga  0  ..  2**10- 1 ; 
aubtypa  UNSIGNBD-11  is  UNSIGNED-LONGWORD  raaga  0  ..  2**11-1; 
subtypa  UNSIGNED-12  is  UNSIGNED-LONGWORD  raaga  0  ..  2  *  * 1 2 - 1 ; 
subtypa  UNSIGN8D.13  is  UNSIGNED  LONGWORD  raaga  0  ..  2*» 13- 1 ; 
subtypa  UNSIGNED-14  is  UNSIGNED-LONGWORD  raaga  0  ..  2**14-1; 

aubtypa  UNSIGNBD-1S  is  UNSIGNBD~LONGWORD  raaga  0  ..  2**15-1; 

subtypa  UNSIGNED-16  is  UNSIGNED-LONGWORD  raaga  0  ..  2**16-1; 

subtypa  UNSIGNED-17  is  UNSIGNED-LONGWORD  raaga  0  ..  2**  17- 1 ; 

subtypa  UNSIGNED-18  is  UNSIGNED-LONGWORD  raaga  0  ..  2»*  18-1; 

aubtypa  UNSIGNBD-19  is  UNSIGNED_LONGWORD  raaga  0  ..  2**19-1; 

aubtypa  UNSIGNBD.20  is  UNSIGNE' _  ONGWORD  raaga  0  ..  2**20- 1; 
aubtypa  UNSIGNBD-21  is  UNSIGNEL  ..ONGWORD  raaga  0  ..  2**21-1; 
subtypa  UNSIGNED.22  is  UNSIGNED  LONGNORD  raaga  0  ..  2**22- 1; 
subtypa  UNSIGNED.23  is  UNSIGNED  LONGWORD  raaga  0  ..  2**23-l; 
subtypa  UNSIGNED.24  is  UNSIGNED  LONGWORD  raaga  0  ..  2**24-l; 
subtypa  UNSIGN8D.2S  is  UNSIGNED-LONGWORD  raaga  0  ..  2**25-l; 
subtypa  UNSIGNBD-26  is  UNSIGNED-LONGWORD  raaga  0  ..  2«*26-l; 
subtypa  UNSIGNED- 2 7  is  UNSIGNED  LONGWORD  raaga  0  ..  2**27- 1 ; 
aubtypa  UNSIGNED_28  is  UNS I GNED.LONGWOPD  raaga  0  ..  2**28-l; 
aubtypa  UNSIGN8D-29  is  UNS I GNBD_LONGWORD  raaga  0  ..  2**29-l; 
aubtypa  UNSIGNED-30  is  UNSIGNED_LONGWORD  raaga  0  ..  2**30-l; 
subtypa  UNSIGNED-31  is  UNSIGNED  LONGWORD  raaga  0  ..  2**31- 1 ; 
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I3.7a.4  Conventional  Names  for  Unsigned  Longwords 


13.7.1  System-Dependent  Named  Numbers 

In  XD  Ada,  the  values  for  system-dependent  named  numbers  are  as 
shown  in  the  following  table. 


Attribute 

MIL-STD-1750A 

MIN.1NT 

-23* 

MAX.INT 

23,-l 

MAX.DIGITS 

9 

MAX.MANTISSA 

31 

F1NE.DELTA 

2.0-31 

TICK 

100.0  x  10-6 

13.7.2  Representation  Attributes 

The  following  information  supplements  all  of  this  section: 

For  any  object,  program  unit,  label,  or  entry  X: 

X' ADDRESS  Yields  the  address  of  the  first  of  the  storage  ele¬ 
ments  allocated  to  X.  For  a  subprogram,  package, 
task  unit  or  label,  this  value  refers  to  the  machine 
code  associated  with  the  corresponding  body  or 
statement.  For  an  entry  for  which  an  address 
clause  has  been  given,  the  value  refers  to  the  offset 
of  the  interrupt  vector  from  the  vector  base  register. 
The  value  of  this  attribute  is  of  the  type  ADDRESS 
defined  in  the  package  SYSTEM. 

For  an  object  that  is  a  variable,  the  value  is  the  ac¬ 
tual  address  of  the  variable  (which  may  be  statically 
or  dynamically  allocated).  This  attribute  forces  a 
variable  to  be  allocated  in  memory  rather  than  in 
a  register,  and  causes  the  variable  to  be  marked  as 
volatile  for  the  duration  of  the  block  statement  or 
body  containing  use  of  the  attribute.  If  the  location 
of  the  variable  is  not  word-aligned,  the  value  is 
the  address  of  the  lowest  word  that  contains  the 
variable.  For  an  object  that  is  a  constant,  the  value 
is  the  address  of  the  constant  \  alue  in  memory; 
however,  two  occurrences  of  C' ADDRESS,  where 
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C  denotes  a  constant,  may  or  may  not  yield  the 
same  address  value.  For  an  object  that  is  a  named 
number,  the  value  is  zero  (ADDRESS.ZERO). 

NOTE 

In  the  context  of  these  representation 
attributes,  ADDRESS.ZERO  means  only 
that  no  useful  interpretation  of  a  nonzero 
value  is  currently  supported.  That  is,  its 
use  as  a  result  of  C' ADDRESS  is  subject 
to  change. 

For  an  access  object,  X.all' ADDRESS  is  the  address 
of  the  designated  object;  X.all' ADDRESS  is  subject 
to  an  ACCESS.CHECK  for  the  designated  object. 
For  a  record  component,  X.C' ADDRESS  is  subject 
to  a  DISCRIMINANT.CHECK  for  an  object  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)' ADDRESS  or  X(I1...I2)' ADDRESS  is  subject  to 
an  INDEX.CHECK  for  the  denoted  component  or 
slice. 

For  program  units  that  are  task  units  or  package 
units,  the  value  is  zero  (ADDRESS.ZERO).  For 
program  units  that  are  subprograms,  the  value  is 
the  same  as  the  address  that  would  be  exported. 
(See  Section  13.9a.l.4  (LRM)  for  information  on 
pragmas  EXPORT_FUNCTION  and  EXPORT. 
PROCEDURE). 

For  entries,  the  value  is  zero  (ADDRESS.ZERO). 

For  labels,  the  value  is  the  address  of  the  machine 
code  which  follows  the  label. 

For  any  type  or  subtype  X,  or  for  any  object  X: 

X'SIZE  For  a  type  or  a  subtype,  the  value  is  limited  to 

valaes  in  the  range  0  ..  MAX.INT;  the  exception 
NUMERIC. ERROR  (set  Section  11.1)  is  raised  for 
values  outside  this  range.  For  an  object  that  is  a 
variable  or  a  constant  in  XD  Ada,  the  value  is  its 
size  in  bits.  For  an  object  that  is  a  named  num¬ 
ber,  the  value  is  zero.  For  a  record  component, 
X.C 'SIZE  is  subject  to  a  DISCRIMINANT.CHECK 
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Representation  Attributes  13.7.2 


for  an  object  in  a  variant  part.  For  an  array  compo- 
•  nent  or  slice,  X(I)'SIZE  or  X(I1..I2)'SIZE  is  subject 
to  an  INDEX.CHECK  for  the  denoted  component 
or  slice. 

For  any  type  or  subtype  X: 

X'MACHINE.SIZE  Yields  the  number  of  machine  bits  to  be  allo¬ 
cated  for  variables  of  the  type  or  subtype.  This 
value  takes  into  account  any  padding  bits  used 
by  XD  Ada  when  allocating  a  variable  on  a  word 
boundary.  The  value  of  this  attribute  is  of  the  type 
universal Jnteger. 

The  value  is  always  a  multiple  of  16  (bits).  In 
particular,  tor  discrete  types  it  is  16,  or  32.  The 
value  is  limited  to  the  range  0..MAXJNT;  the 
exception  NUMERIC. ERROR  is  raisec.  for  values 
outside  this  range. 

For  any  object  X: 

X'BIT  Yields  the  bit  offset  within  the  storage  unit  (word) 

that  contains  the  first  bit  of  the  storage  allocated  for 
the  object.  The  value  of  this  attribute  is  of  the  type 
universaljnteger,  and  is  always  in  the  range  0..15 

For  an  object  that  is  a  variable  or  a  constant  al¬ 
located  in  a  register,  the  value  is  zero.  (The  use 
of  this  attribute  does  not  force  the  allocation  of 
a  variable  to  memory.)  For  an  object  that  is  a 
formal  parameter,  this  attribute  applies  either 
to  the  matching  actual  parameter  or  to  a  copy 
of  the  matching  actual  parameter.  For  an  ac¬ 
cess  object,  the  value  is  zero  (in  the  absence  of 
CONSTRAINT-ERROR);  X.all'BIT  is  subject  to 
an  ACCESS.CHECK  for  the  designated  object. 

For  a  record  component,  X.C'BIT  ir  'ubject  to 
a  DISCRIMINANT.CHECK  for  a  component  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)'BIT  or  X(U..I2)'BIT  is  subject  to  an  INDEX. 
CHECK  for  the  denoted  component  or  slice. 
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The  following  information  supplements  the  Notes  section: 

The  attribute  X '  MACHINE_SIZE  gives  the  size  that  would  be  used  for 
a  variable  of  the  type  or  subtype;  it  does  not  give  the  size  that  may  be 
used  for  a  component  of  that  type  or  subtype. 

The  machine  size  of  a  type  or  subtype  can  be  influenced  by  representa¬ 
tion  clauses,  unlike  the  size  of  a  type  or  subtype,  which  is  independent 
of  representation  clauses.  The  machine  size  of  a  base  type  can  be  less 
than,  equal  to,  or  greater  than  the  size  of  that  same  base  type.  See  the 
XD  Ada  MIL-STD-1750A  Run-Time  Reference  Manual  for  examples  and 
additional  discussion. 


13.7.3  Representation  Attributes  of  Real  Types 

The  following  information  supplements  paragraphs  3  and  4: 

For  both  fixed-  and  floating-point  types: 

T '  MACH1NE.ROUNDS  In  XD  Ada  this  value  is  FALSE 

T '  MACHINE.O  VERFLOWS  in  XD  Ada  this  value  is  FALSE 

The  XD  Ada  values  of  the  other  representation  attributes  for  floating¬ 
point  types  are  dependent  on  the  floating-point  type  and  are  listed  in 
Appendix  F. 


1 3.8  Machine  Code  insertions 

The  following  information  supplements  paragraph  4: 

XD  Ada  provides  the  package  MACHINE_CODE.  Machine  code  inser¬ 
tions  can  be  expanded  in  line. 

This  predefined  package  and  not  a  user-defined  package  must  be 
named  in  a  with  clause  that  applies  to  the  compilation  unit  in  which  the 
code  statement  occurs. 

The  following  is  an  example  of  MACHINE_CODE  and  the  with  clause 
in  use: 
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with  HACHINB.CODE; 

procedure  INC  (  N:  in  out  INTEGER); 

pragma  CALL_SEQUENCE_PROCEDURE  ( 

INC, 

MECHANISM  ->  (VALUE  (R4)  ), 

PRBSERVED_REGISTERS  ->  (RO,  Rl,  R2,  R3,  R5,  R6, 

R7,  R8,  R9 ,  R12,  R13,  R14  )); 

proeadura  INC  (  Ni  in  out  INTEGER)  ia 

bag  in 

AISP_INST' (OPCODE  ->  AISP, 

RA  “>  R4, 

N  ->  Nl); 


and  INC; 

XD  Ada  provides  the  pragma  CALL.SEQUENCE.PROCEDURE  which 
specifies  parameter-passing  mechanisms  for  machine  code  procedures. 
The  pragma  is  defined  in  Appendix  B.  Examples  of  machine  code  in¬ 
sertion  are  given  in  Section  6.1  of  the  XD  Ada  MIL-STD-1750A  Run-Time 
Reference  Manual.  For  the  specification  of  the  package  MACHINE. 
CODE,  see  Appendix  D  of  the  XD  Ada  MIL-STD-1750A  Run-Time 
Reference  Manual. 


1 3.9  Interface  to  Other  Languages 

The  following  information  supplements  paragraph  4: 

As  with  VAX  Ada,  use  of  pragma  INTERFACE  in  XD  Ada  is  interpreted 
as  being  equivalent  to  supplying  the  body  of  the  named  subprogram  or 
subprograms.  Therefore,  the  following  rules  apply: 

If  a  subprogram  body  is  given  later  for  a  subprogram  named  with 
pragma  INTERFACE,  the  body  is  illegal. 

•  If  pragma  INTERFACE  names  a  subprogram  body,  the  pragma  is 
illegal. 

•  If  a  duplicate  pragma  INTERFACE  is  given,  the  latter  pragma  is 
illegal. 

In  XD  Ada,  pragma  INTERFACE  applies  to  a  renaming  only  if  the 
renaming  occurs  in  the  same  declarative  part  or  package  specification 
as  the  pragma.  The  renamed  subprogram  must  also  occur  in  that  same 
declarative  part  or  package  specification;  renamed  subprograms  that 
occur  outside  the  declarative  part  or  package  specification  are  ignored 
(without  a  warning  diagnostic). 
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In  addition,  XD  Ada  interprets  the  effect  of  pragma  INTERFACE  in  such 
a  way  that  it  accepts  and  ignores  implicit  ’  clarations  of  subprograms 
(such  as  predefined  operators,  derived  subprograms,  attribute  functions, 
and  so  on). 

Dependent  upon  its  use  in  an  XD  Ada  program,  pragma  INTERFACE  is 
interpreted  in  combination  with  one  of  two  XD  Ada  import  subprogram 
pragmas:  IMPORT.FUNCTION  or  IMPORT.PROCEDURE.  These 
pragmas  are  described  in  Section  13.9a.l. 

The  language  name  is  ignored,  and  so  may  be  any  identifier  that 
suggests  the  language,  source,  or  nature  of  the  imported  subprogram. 

If  pragma  INTERFACE  is  used  without  one  of  these  import  pragmas,  a 
default  interpretation  is  used,  as  follows: 

•  If  the  subprogram  name  applies  to  a  single  subprogram,  then  a 
default  import  pragma  is  assumed  as  follows: 

For  a  function,  the  default  is  as  follows: 

pragma  IMPORT_FUNCTION  (function_designator ) ; 

For  a  procedure,  the  default  is  as  follows: 

pragma  IMPORT_PROCEDURE  ( procedure_identif ier ) ; 

•  If  the  subprogram  name  applies  to  two  or  more  subprograms,  the 
pragma  applies  to  all  of  them.  However,  a  warning  is  given  if  the 
appropriate  XD  Ada  import  pragmas  are  not  given  for  all  of  the 
subprograms. 

Whether  or  not  pragma  INTERFACE  is  used  with  an  import  pragma,  the 
subprogram  name  must  be  an  identifier,  or  a  string  literal  that  denotes 
an  operator  symbol.  In  the  following  example,  pragma  INTERFACE 
specifies  that  the  indicated  routines  SQRT  and  EXP  are  to  be  imported 
and  used  as  bodies  for  the  XD  Ada  functions  SQRT  and  EXP  in  package 
FORT.UB: 

packaga  FORT_LIB  is 

fraction  SQRT(X  i  FLOAT)  rsturn  FLOAT; 
function  EXP( X  i  FLOAT)  roturo  FLOAT; 
private 

pragma  INTERFACE ( FORTRAN ,  SQRT); 
pragma  INTERFACE (FORTRAN,  EXP); 
on4  FORT.LIB; 
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The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  example  package  FORT. LIB  is  interpreted  as  follows: 
pragma  INTERFACE  specifies  that  the  indicated  routines  SQRT  and 
EXP  are  to  be  imported  and  used  as  bodies  for  the  Ada  functions  SQRT 
and  EXP  in  package  FORT.LIB. 

package  CHOOSE.R  la 

procedure  pjx  I  INTEGER); 
procedure  P(X  >  FLOAT); 

private 

procedure  R(X  t  FLOAT)  renames  P; 
pragma  INTERFACE) ASSEMBLER,  R) ; 
end  CHOOSE.R; 

In  this  example,  pragma  INTERFACE  indicates  that  the  body  for  the 
second  procedure  P  is  to  be  imported  as  routine  R. 

The  following  information  supplements  the  Notes  section: 

The  meaning  of  the  subprogram  name  i.®  determined  as  for  any  name 
(see  Section  8.3  (LRM)),  except  that  the  name  can  denote  more  than  one 
subprogram.  Thus,  in  the  following  declaration  the  pragma  INTERFACE 
applies  to  the  first  two  procedures;  it  does  not  apply  to  the  third 
because  the  declaration  is  not  visible  at  the  place  of  the  pragma. 

procedure  P  (Bt  BOOLEAN); 
procedure  P  (Ii  INTEGER); 
pragma  INTERFACE  (ASSEMBLER,  P); 
proeadura  P  (Fl  FLOAT); 

This  same  interpretation  is  made  for  pragmas  used  to  import  and  export 
subprograms  (see  Section  13.9a.l). 

If  pragma  INTERFACE  and  pragma  INLINE  are  used  together,  the 
pragma  INLINE  is  ignored  regardless  of  the  order  in  which  the  two 
pragmas  appear. 

Refer  to  Chapter  3  of  the  XD  Ada  MIL-STD-1750A  Run-Time  Reference 
Manual  for  subprogram  calling  conventions  and  run-time  organisation, 
while  Chapter  6  of  the  same  manual  describes  low-level  interfaces  and 
assembly  language  modules. 


13.9  Interface  to  Other  Languages 


13-19 


1 3.9a  XD  Ada  Import  and  Export  Pragmas 

XD  Ada  provides  import  and  export  pragmas  designed  specifi¬ 
cally  for  constructing  programs  composed  of  both  Ada  and  non- 
Ada  entities.  The  import  pragmas  allow  an  Ada  program  to  refer 
to  entities  written  in  another  language;  the  export  pragmas  make 
Ada  entities  available  to  programs  written  in  other  languages. 

The  names  of  the  pragmas  indicate  the  kind  of  entity  involved: 
IMPORT.FUNCTION  and  EXPORT_FUNCTION  apply  to  nongeneric 
functions;  IMPORT.PROCEDURE  and  EXPORT.PROCEDURE  apply  to 
nongeneric  procedures;  IMPORT.OBJECT  and  EXPORT.OBJECT  apply 
to  objects;  and  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION  apply 
to  exceptions.  These  pragmas  are  described  in  this  section,  summarized 
in  Annex  B,  and  listed  in  Appendix  F. 

All  the  XD  Ada  import  and  export  pragmas  have  the  following  form: 

pragas  import_export_pragma_n<une 

<intarnal_name  [,  extsrnal_deBlgnator ) 

(,  pragma_specif ic_options ] ) ; 

import_axport_pragma_nama  ti* 

EXPORT^EXCEPTION  EXPORT_FUNCTION 
BXPORT~OBJECT  EXPORT“pROCEDURB 

IMPORt”eXCEPTION  IMPORT” FUNCTION 

import”object  import”procedurb 

inter nal_name  n«  {INTERNAL  »>]  simple_naine 

|  (INTERNAL  •>)  operator  symbol  —  Can  be  used  only  for 

"  IMPORT_FUNCTlON 

extsrnal_designator  n«  [EXTERNAL  «>]  external_symbol 

external_symbol  l I «  identifier  |  string_literal 

The  internal  name  can  be  an  Ada  simple  name,  or,  if  the  declared  entity 
is  a  function,  the  internal  name  can  be  a  string  literal  that  denotes  an 
operator  symbol.  A  subprogram  to  be  imported  or  exported  must  be 
identified  by  its  internal  name  and  parameter  types;  and,  in  the  case  of 
a  function,  by  the  result  .type  (see  Section  13.9a.l.l). 

The  external  designator  determines  a  symbol  that  is  referenced  or 
declared  in  the  linker  object  module.  If  an  identifier  is  given,  the 
identifier  is  used.  If  a  string  literal  is  given,  the  value  of  the  string  is 
used.  The  value  of  a  string  literal  must  be  a  symbol  that  is  acceptable 
to  the  XD  Ada  Builder;  it  need  not  be  valid  as  an  Ada  identifier.  (For 
example,  the  dollar  character  ($)  can  be  used.)  If  no  external  designator 
is  given,  the  internal  name  is  used  as  the  external  designator.  If  the 
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external  designator  (explicit  or  default)  is  longer  than  12  characters,  the 
import  or  export  pragma  is  ignored. 

Pragma-specific  options  are  described  in  the  individual  pragma  sections 
that  follow. 

The  XD  Ada  import  and  export  pragmas  are  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply  to  an  entity  declared  by  an  earlier 
declarative  item  of  the  same  declarative  part  or  package  specification. 
At  most  one  import  or  export  pragma  is  allowed  for  any  given  entity;  in 
the  case  of  multiple  overloaded  subprograms,  this  rule  applies  to  each 
subprogram  independently. 

Additional  placement  and  usage  rules  apply  for  particular  pragmas  as 
described  in  the  following  sections. 

Not*: 

Argument  associations  for  XD  Ada  import  and  export  pragmas  can  be 
either  positional  or  named.  With  positional  association,  the  arguments 
are  interpreted  in  the  order  in  which  they  appear  in  the  syntax  defini¬ 
tion.  The  rules  for  the  mixing  of  positional  and  named  association  are 
the  same  as  those  that  apply  to  subprograms  (see  Section  6.4  (LRM)). 

A  pragma  for  an  entity  declared  in  a  package  specification  must  not  be 
given  in  the  package  body.  (A  pragma  for  an  entity  given  in  the  visible 
part  of  a  package  specification  can,  however,  be  given  in  either  the 
visible  or  private  part  of  the  specification.) 

No  checking  is  provided  to  ensure  that  exported  symbols  do  not  con¬ 
flict  with  each  other  or  with  other  global  symbols;  such  checking  is 
performed  by  the  XD  Ada  Builder. 


13.9a.1  Importing  and  Exporting  Subprograms 

XD  Ada  provides  a  series  of  pragmas  that  make  it  possible  to  call 
nongeneric  subprograms  in  a  mixed-language  programming  environ¬ 
ment.  The  IMPORT.FUNCTION  and  IMPORT.PROCEDURE  pragmas 
specify  that  the  body  of  the  subprogram  associated  with  an  Ada  sub¬ 
program  specification  is  to  be  provided  from  assembly  language. 
Pragma  INTERFACE  must  precede  one  of  these  import  pragmas  (see 
Section  13.9).  The  EXPORT.FUNCTION  and  EXPORT.PROCEDURE 
pragmas  allow  an  Ada  procedure  or  function  to  be  called  from  assem¬ 
bly  language.  The  pragmas  support  parameter  passing  by  means  of 
registers. 
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13.9a. 1.1  Importing  Subprograms 

XD  Ada  provides  two  pragmas  for  importing  subprograms: 
IMPORT.FUNCTION  and  IMPORT.PROCEDURE.  These  pragmas 
allow  the  import  of  the  kind  of  subprograms  indicated. 

The  pragmas  for  importing  subprograms  have  the  following  form: 

pr««a«  IMPORT_FUNCTION  I  I MPORT_PROCEDURE 

([  INTERNAL  ->)  internal_neune 
[,  [EXTERNAL  ->)  external_designator  ) 

( ,  [ PARAMBTBR_TVPES  -> )  (  parameter_typ«a  )  ) 

[,  [RESULT  TVPE  «>)  typa_mark  )  —  FUNCTION  only 

[,  [MECHANISM  ->)  mechanism  ] 

(,  [RESULT  MECHANISM  »>)  mechanism_spac  )  —  FUNCTION  only 

[,  [ FI RST_OPT I ONAL_ PARAMETER  ->)  FORMAL_NAME] 

[,  (PRESERVED  REGISTERS  ->  ]  (  registers  )  ) 

)> 

parameter  types  tt« 

null  T  type_mark  {,  type_mark) 

mechanism  tt« 

mechanism_tpec  |  (  mechanism_spec  {,  mechanism_spec)  ) 
mechanism_spec  »i» 

mechanism_name  [  (  [REGISTER  »>  )  regiater_name  )  ] 

mechanism_name  tt“ 

VALUE-  | 

REFERENCE  j  BIT_REFERENCE  | 

DOPE_ VECTOR  |  BIT~DOPE_ VECTOR 

registers  u* 

null  |  register^name  {»  register_name  } 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol  that 
is  associated  with  the  external  subprogram.  If  no  external  designator  is 
given,  the  internal  name  is  used  as  the  global  symbol. 
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The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  tne 
reserved  word  null. 


The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 


The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 


Mechanism  names  are  described  as  follows.  Within  these  definitions, 
the  term  bit  string  means  any  one-dimensional  array  of  a  discrete  type 
whose  components  occupy  successive  single  bits.  The  term  simple 
record  type  means  a  record  type  that  does  not  have  a  variant  part  and  in 
which  any  constraint  for  each  component  and  subcomponent  is  static. 

A  simple  record  subtype  is  a  simple  record  type  or  a  static  constrained 
subtype  of  a  record  type  (with  discriminants)  in  which  any  constraint  for 
each  component  and  subcomponent  of  the  record  type  is  static. 


VALUE 


REFERENCE 

DOPE_  VECTOR 


Specifies  that  the  immediate  value  of  the  actual 
parameter  is  passed.  Values  of  scalars,  access 
types,  address  types  and  private  types  whose 
full  type  is  either  a  scalar,  an  access  type  or  an 
address  type  can  be  passed  by  VALUE.  If  the 
value  is  a  private  type,  the  pragma  must  occur 
after  the  full  declaration  of  the  private  type.  Bit 
strings  can  also  be  passed  by  VALUE. 

Specifies  that  the  address  of  the  value  of  the 
actual  parameter  is  passed.  This  mechanism  can 
be  used  for  parameters  of  any  type. 

Specifies  that  the  address  of  the  DOPE, VECTOR 
is  passed,  a  32-bit  pointer  to  an  object,  taking 
the  form  described  in  Section  2.1.4  of  the  XD 
Ada  M1L-STD-1750A  Run-Time  Reference  Manual. 


BIT_DOPE_  VECTOR  Specifies  that  the  address  of  the  BIT_DOPE_ 

VECTOR  is  passed,  a  32-bit  pointer  to  an  object, 
taking  the  form  described  in  Section  2.1.4  of 
the  XD  Ada  MIL-STD-1750A  Run-Time  Reference 
Manual 
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If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
subprograms  are  as  follows; 

•  If  an  import  pragma  is  given  for  a  subprogram  specification,  pragma 
INTERFACE  (see  Section  13.9)  must  also  be  given  for  the  subpro- 

fram  earlier  in  the  same  declarative  part  or  package  specification. 

he  use  of  pragma  INTERFACE  implies  that  a  corresponding  body 
is  not  given. 

•  If  a  subprogram  has  been  declared  as  a  compilation  unit,  the 

pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  These  pragmas  can  be  used  for  subprograms  declared  with  a  re¬ 
naming  declaration.  The  internal  name  must  be  a  simple  name,  and 
the  renaming  declaration  must  occur  in  the  same  declarative  part 
or  package  specification  as  the  pragma.  The  renamed  subprogram 
must  also  occur  in  that  same  declarative  part  or  package  specifica¬ 
tion.  Renamed  subprograms  that  occur  outside  the  declarative  part 
or  package  specification  are  ignored  (without  a  warning  diagnostic). 

•  None  of  these  pragmas  can  be  used  for  a  generic  subprogram  or 
a  generic  subprogram  instantiation.  In  particular,  they  cannot  be 
used  for  a  subprogram  that  is  declared  by  a  generic  instantiation  of 
a  predefined  subprogram  (such  as  UNCHECICED_CONVERSION). 
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Examples: 

In  this  example,  the  pragma  INTERFACE  identifies  SQRT  as  an  external 
subprogram;  the  language  name  argument  ASSEMBLER  has  no  effect. 
The  pragma  IMPORT. FUNCTION  uses  positional  notation  to  specify 
arguments  for  importing  the  declared  function  SQRT.  The  pragma  form 
indicates  that  the  internal  name  is  SQRT,  and  the  external  designator  is 
"MTHSSQRT*.  The  parameter  is  of  type  FLOAT,  and  is  passed  in  R4; 
the  result  is  of  type  FLOAT,  and  it  is  returned  in  R6. 


function  SQRT  (X  ■  FLOAT  )  return  FLOAT; 
pragma  INTERFACE  (ASSEMBLER,  SQRT); 
pragma  IMPORT.FUNCTION 

(SQRT,  "MTHSSQRT",  (FLOAT), 
FLOAT,  ( VALUE ( R4 ) ) ,  VALUE (R6) 
)J 


The  next  example  shows  an  alternative  way  of  importing  the  declared 
function  SQRT  using  named  notation.  In  this  case,  the  parameter  is 
passed  in  R7,  and  the  result  is  returned  in  R4;  the  registers  which  are 
preserved  by  the  called  function  are  also  specified. 


fttactlaa  SQRT  (X  i  LONG.FLOAT  )  raturn  LONQ_FLOAT; 
pragma  INTERFACE  (ASSEMBLER,  SQRT); 
pragma  IMPORT  FUNCTION  (INTERNAL 

PARAMBTER.TYPES 
RESULT.TYPB 
MECHANISM 
RESULT_MECHAN I SM 
EXTERNAL 

PRESERVBD.REGI STERS 


»>  SQRT, 

->  (LONG_FLOAT) , 
»>  LONG. FLOAT, 

»>  ( VALUE ( R7 ) ) , 
»>  VALUE (R4), 

->  "MTHSDSQRT", 
»> 


(RO,  Rl,  R2 ,  R3,  R12,  R13,  R14;); 


If  the  previous  example  is  combined  with  the  code  in  the  first  example 
(that  is,  with  only  one  occurrence  of  pragma  INTERFACE),  the  result  is 
an  overloading  of  SQRT: 
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function  SQRT  (X  l  LONG_ FLOAT  )  roturn  LONG. FLOAT; 
function  SQRT  (X  i  FLOAT  )  return  FLOAT; 
pragaa  INTERFACE  (ASSEMBLER,  SQRT); 
pragma  IMPORT.FUNCTION  (SQRT, 

"MTHSSQRT" , 

(FLOAT), 

FLOAT, 

( VALUE ( R4 ) ) , 

VALUE ( R6 ) ) ; 

pragaa  IMPORT_FUNCTION  (INTERNAL 

PARAMETBR.TYPBS 
RESULT.TYPE 
MECHANISM 
RESULT_MBCHANISM 
EXTERNAL 
PRBSERVED_RBGISTERS  -> 

(RO,  Ri,  R2,  R3,  R12,  '•13,  R14))} 

The  next  example  shows  the  use  of  renaming  with  an  imported  pro¬ 
cedure  (it  is  assumed  that  these  declarations  occur  in  a  declarative 
part  or  package  specification).  Note  that  the  renaming  causes  the  im¬ 
ported  ASSEMBLER  procedure  to  be  used  in  calls  to  both  procedures 
CHANGE  and  EXCHANGE.  Also  note  that  because  no  external  desig¬ 
nator  is  specified,  the  builder  global  symbol  associated  with  the  external 
subprogram  is  EXCHANGE,  and  because  no  parameter  mechanisms 
are  specified,  the  compiler's  defaults  will  apply  in  calls  to  CHANGE  or 
EXCHANGE. 

proeadurs  CHANGE  (X,Y  1  INTEGER); 

procadura  EXCHANGE  (X,Y  i  INTEGER)  ranaaaa  CHANGE; 

pragaa  INTERFACE  (ASSEMBLER,  EXCHANGE); 

pragaa  IMPORT.PROCEDURE  (INTERNAL  ->  EXCHANGE, 

PARAMETER  TYPES  ->  ( INTEGER, INTEGER) ) ; 


->  SQRT, 

»>  ( LONG_ FLOAT ) , 
->  LONG  FLOAT, 
->  ( VALUE ( R7 ) ) , 
->  VALUE (R4), 

»>  "MTHSDSQRT" , 


13.9a.  1.2  Exporting  Subprograms 

XD  Ada  provides  two  pragmas  for  exporting  subprograms: 
EXPORT.FUNCTION  and  EXPORT.PROCEDURE.  Both  export  prag¬ 
mas  establish  an  external  name  for  a  subprogram  and  make  the  name 
available  to  the  XD  Ada  Builder  as  a  global  symbol,  so  that  the  subpro¬ 
gram  can  be  called  by  in  assembly  language  module. 

The  EXPORT.FUNCTION  and  EXPORT.PROCEDURE  pragmas  allow 
the  export  of  the  kind  of  subprograms  indicated. 
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The  pragmas  for  exporting  subprograms  have  the  following  form: 

pra«M  EXPORT_FUNCTION  |  EXPORT_ PROCEDURE 

(  (  INTERNAL  •>]  internal_name 

{/  [EXTERNAL  «>)  external_designator  ) 

[,  [ PARAMBTER_TYPES  »>|  (”parameter_types  )  J 
(,  [RESULT.TYPE  ->)  type_mark  1  —  FUNCTION  only 

[,  [MECHANISM  •>)  mechanism  ) 

{,  [RESULT  MECHANISM  ->)  mechanism  spec  ]  —  FUNCTION  only 

) ; 

parameter_types  i t - 

null  |  type_mark  {,  type_mark) 

mechanism  i i » 

mechanism_spec  |  (  mechanism_spec  {,  mechanism_spec)  ) 
mechanism_spec  j»» 

mechanism_najne  [  (  [REGISTER  »>  )  register_name  )  ] 

mechanism  name  t«« 

VALUE-  | 

REFERENCE  j  BIT_REFERENCE  | 

DOPE_ VECTOR  |  BIT~DOPE_VECTOR 

registers  i i« 

null  |  regiater_name  {,  register_name  > 

parameter_types  « i - 

null  |  type_mark  {,  type_mark} 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol 
that  is  associated  with  the  external  subprogram.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 
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The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine.  Mechanism  options  and  possible 
values  for  mechanism  names  and  class  names  are  described  in  Section 
13.9a.l.l. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  ail  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  exporting 
subprograms  are  as  follows: 

•  An  exported  subprogram  must  be  a  library  unit  or  be  declared  in 
the  outermost  declarative  part  of  a  library  package.  Thus,  pragmas 
for  exporting  subprograms  are  allowed  only  in  the  following  cases: 

—  For  a  subprogram  specification  or  a  subprogram  body  that  is  a 
library  unit 

—  For  a  subprogram  specification  that  is  declared  in  the  outermost 
declarations  of  a  package  specification  or  a  package  body  that  is 
a  library  unit 

—  For  a  subprogram  body  that  is  declared  in  the  outermost  decla¬ 
rations  of  a  package  body  that  is  a  library  unit 

Consequently,  an  export  pragma  for  a  subprogram  body  is  allowed 
only  if  either  the  body  does  not  have  a  corresponding  specification, 
or  the  specification  and  body  occur  in  the  same  declarative  part. 

This  set  of  rules  implies  that  an  EXPORT_FUNCTION  or 
EXPORT_PROCEDURE  pragma  cannot  be  given  for  a  generic  li¬ 
brary  subprogram,  nor  can  one  be  given  for  a  subprogram  declared 
in  a  generic  library  package.  However,  either  of  these  pragmas 
can  be  given  for  a  subprogram  resulting  from  the  instantiation  of 
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a  generic  subprogram,  provided  that  the  instantiation  otherwise 
satisfies  this  set  of  rules. 

•  In  the  case  of  a  subprogram  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  with  a  renaming  declaration. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  by  a  generic  instantiation  of  a  built-in  library  subprogram 
(such  as  UNCHECKED.CONVERSION). 

Examples: 

The  following  example  shows  an  export  pragma  that  causes  the  Ada 
procedure  PROC  to  be  exported  for  use  in  an  assembly  language 
module.  The  name  PROC  is  declared  as  an  XD  Ada  Builder  global 
symbol. 

procadura  PROC  (Y  t  INTEGER); 
pragma  EXPORT_PROCEDURE  (PROC); 

The  next  example  shows  an  Ada  function  being  called  from  an  assembly 
language  module:. 

fuactioa  MULTIPLY  (Y  i  ia  INTEGER)  ratura  INTEGER  la 


bagia 

aad; 

pragma 

ratura  Y  »  10; 

EXPORT.FUNCTION  (  INTERNAL  ->  MULTIPLY, 

PARAMETER  TYPES 

->  (INTEGER), 

RESULT.TYPE 

->  INTEGER  ) ; 

pragma 

CALL_SEQUENCE_FUNCTION  ( 

UNIT 

->  MULTIPLY, 

PARAMETERJTYPES 

->  (INTEGER), 

MECHANISM 

->  ( VALUE  ( DO )  ) 

RESULT.MECHANISM 

1  ->  VALUE ( DO ) ) ; 

TITLE  "I750A  Calling  Ada" 
MODULE  "CALL_ADA" 

XDEF  CALL.ADA 
XR1F  MULTIPLY 

DSBG 

At  BLEW  1 
PSEG 
CALL. ADA 
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1  antry  sequence 

L  R4,  A  !  in  parameter 

JS  RIO, MULTIPLY  !  call 

ST  R4,A  !  out  parameter 

l  return  from  subroutine 


13.9a.2  Importing  and  Exporting  Objects 

XD  Ada  provides  two  pragmas  for  importing  and  exporting  objects: 
IMPORT, OBJECT  and  EXPORT.OBJECT.  The  IMPORT_OBJECT 
pragma  references  storage  declared  in  an  assembly  language  module. 

1».  i  EXPORT.OBJECT  pragma  allows  an  assembly  language  module  to 
refer  to  the  storage  allocated  for  an  Ada  object. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
and  exporting  objects  are  as  follows: 

•  The  object  to  be  imported  or  exported  must  be  a  variable  declared 
by  an  object  declaration  at  the  outermost  level  of  a  library  package 
specification  or  body. 

•  The  subtype  indication  of  an  object  to  be  imported  or  exported  must 
denote  one  of  the  following: 

—  A  scalar  type  or  subtype. 

—  An  array  subtype  with  static  index  constraints  whose  component 
size  is  static. 

—  A  record  type  or  subtype  that  does  not  have  a  variant  part  and 
in  which  any  constraint  for  each  component  and  subcomponent 
is  static  (a  simple  record  type  or  subtype). 

•  Import  and  export  pragmas  are  not  allowed  for  objects  declared 
with  a  renaming  declaration. 

•  Import  and  export  pragmas  for  objects  are  not  allowed  in  a  generic 
unit. 

Notes: 

Objects  of  private  or  limited  private  types  cannot  be  imported  or 
exported  outside  the  package  that  declares  the  (limited)  private  type. 
They  can  be  imported  or  exported  inside  the  body  of  the  package  where 
the  type  is  declared  (that  is,  where  the  full  type  is  known). 

The  XD  Ada  pragmas  for  importing  or  exporting  objects  can  precede  or 
follow  a  pragma  VOLATILE  for  the  same  objects  (see  Section  9.11). 
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Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored  (see  Section  13.5). 


13.9a.2.1  Importing  Objects 

The  XD  Ada  IMPORT_OBJECT  pragma  specifies  that  the  storage  allo¬ 
cated  for  the  object  (when  the  assembly  language  module  is  compiled) 
be  made  known  to  the  calling  Ada  program  by  an  externally-defined  XD 
Ada  Builder  global  symbol. 

Pragma  IMPORT_OBJECT  has  the  following  form: 

pragma  itr  orT_object 

(internal_name  (,  external_designator ) > 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  extern^  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Because  it  is  not  created  by  an  Ada  elaboration,  an  imported  object 
cannot  have  an  initial  value.  Specifically,  this  restriction  means  that  the 
object  to  be  imported: 

•  Cannot  be  a  constant  (have  an  explicit  initial  value). 

•  Cannot  be  an  access  type  (which  has  a  default  initial  value  of  null). 

•  Cannot  be  a  record  type  that  has  discriminants  (which  are  always 
initialized)  or  components  with  default  initial  expressions. 

•  Cannot  be  an  object  of  a  task  type. 

Exampla: 

PIDi  INTEGER; 

pragma  IMPORT.OBJECT  (PID,  "PROCESSSID" ) ; 

In  this  example,  the  variable  PID  refers  to  the  externally-defined  symbol 
PROCESSSID. 

Alternatively,  this  example  can  be  written  in  named  notation  as  follows: 

PID  l  INTEGER; 

pragma  IMPORT_OBJECT  (INTERNAL  ->  PID, 

EXTERNAL  »>  "PROCESSSID"); 
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13.9a.2.2  Exporting  Object* 

The  XD  Ada  pragma  EXPORT, OBJECT  specifies  that  the  storage  al¬ 
located  for  the  object  (when  the  Ada  program  is  compiled)  be  made 
known  to  assembly  language  modules  by  an  XD  Ada  Builder  global 
symbol. 

Pragma  EXPORT_OBJECT  has  the  following  form: 

pragma  EXPORT_OBJECT 

( inter nal_name  {,  external_deaignator ] ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Exampli: 

PIDl  INTEGER? 

pragma  EXPORT_OBJECT  (PID,  "PR0CESS5ID" ) ; 

Alternatively,  this  example  can  be  written  in  named  notation: 

PIDl  INTEGER! 

pragma  EXPORT_OBJECT  (INTERNAL  ->  PID, 

EXTERNAL  «>  "PROCESSSID" ) ? 


13.9a.3  Importing  and  Exporting  Excaptions 

XD  Ada  provides  the  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION 
pragmas  for  importing  and  exporting  exceptions.  The  pragma  IMPORT, 
EXCEPTION  allows  non-Ada  exceptions  to  be  used  in  Ada  programs; 
the  pragma  EXPORT, EXCEPTION  allows  Ada  exceptions  to  be  used  by 
foreign  emits. 

The  rules  for  importing  and  exporting  exceptions  are  given  in  Section 
13.9a. 

Not*: 

A  pragma  for  an  exception  that  is  declared  in  a  package  specification  is 
not  allowed  in  the  package  body. 
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13.9a.3.1  Importing  Excaptions 

The  XD  Ada  IMPORT.EXCEPTION  pragma  is  provided  for  compatibil¬ 
ity  with  VAX  Ada.  This  pragma  specifies  that  the  exception  associated 
with  an  exception  declaration  in  an  Ada  program  be  defined  externally 
in  non-Ada  code. 

In  XD  Ada  pragma  IMPORT_EXCEPTION  has  the  following  form: 

pragma  IMPORT.EXCEPTION 

( internal_name  [,  external_designator ) 

(,  [FORM  ->]  ADA  )),- 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

For  compatibility  with  VAX  Ada,  the  form  option  indicates  that  an  Ada 
exception  is  being  imported.  If  omitted,  this  defaults  to  ADA. 

The  external  designator  refers  to  an  address  that  identifies  the  excep¬ 
tion. 

The  VAX  Ada  version  of  this  pragma  supports  an  alternative  form 
(VMS),  and  a  code  option  in  addition  to  the  XD  Ada  arguments.  If 
either  of  these  unsupported  arguments  is  specified,  the  compiler  ignores 
the  pragma  and  issues  a  warning  message. 


13.9a. 3.2  Exporting  Excaptions 

The  XD  Ada  EXPORT.EXCEPTION  pragma  allows  Ada  exceptions  to 
be  visible  outside  the  XD  Ada  program,  so  that  they  can  be  raised  and 
handled  by  programs  written  in  XD  Ada  MIL-STD-1750A  assembly 
language.  This  pragma  establishes  an  external  name  for  an  Ada  excep¬ 
tion  and  makes  the  name  available  to  the  XD  Ada  Builder  as  a  global 
symbol.  Refer  to  the  XD  Ada  MIL-STD-1750A  Run-Time  Reference  Manual 
for  further  information  on  exporting  exceptions. 

Pragma  EXPORT. EXCEPTION  has  the  following  form: 

pra«a«  EXPORT.EXCEPTION 

(internal  name  [,  external_designator ) 

(,  [FORM  <■>]  ADA  ])l 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception. 
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The  form  option  specifies  that  an  Ada  exception  is  being  exported. 

Example: 

UNDERFLOW  t  exception 

pragma  EXPORT_EXCEPTION  (UNDERFLOW,  MTHJJNDBRFLOW,  ADA); 

In  this  example,  an  Ada  exception  is  exported  as  a  global  symbol. 


13.10  Unchecked  Programming 

13.10.1  Unchecked  Storage  Deallocation 

The  following  information  supplements  the  Notes  section: 

Because  UNCHECKED_DEALLOCATION  is  a  predefined  generic  pro¬ 
cedure,  XD  Ada  does  not  allow  the  use  of  the  IMPORT_PROCEDlfRE 
pragma  to  substitute  an  alternative  procedure  body. 


13.10.2  Unchecked  Type  Conversions 

The  following  information  supplements  paragraph  2: 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  following  restrictions  on  the  class  of  types  involved: 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  array  type. 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  type  with  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value 
resulting  from  a  call  of  the  conversion  function  resulting  from  an  instan¬ 
tiation  of  UN CHECKED_CONVERSION  is  checked  to  ensure  that  the 
discriminants  satisfy  the  constraints  of  the  actual  subtype. 

The  effect  with  XD  Ada  is  as  if  the  source  value  is  copied  one  word 
in  ascending  order  of  address,  into  the  destination,  also  in  ascending 
order  of  address.  If  the  destination  has  fewer  words  than  the  source 
value,  the  high  order  words  of  the  source  value  are  ignored  (truncated). 
If  the  source  value  has  fewer  words  than  the  destination,  the  high  order 
words  of  the  destination  are  set  to  zero. 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


This  chapter  describes  XD  Ada  MIL-STD-1750A  Version  1.2  interrupt 
handling.  In  particular,  it  describes  the  handling  of  direct  interrupt 
entries,  and  use  of  pragma  DIRECT_INTERRUPT_ENTRY. 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  MIL-STD-1750A  interrupt  number. 

In  addition  to  support  for  normal  Ada  interrupt  entries,  XD  Ada 
provides  the  additional  pragmas  LEVEL  and  D1RECT_INTERRUPT_ 
ENTRY.  Pragma  LEVEL  is  given  for  a  task  type,  or  single  task  of  anony¬ 
mous  type,  and  gives  the  level  for  its  interrupts.  Pragma  DIRECT. 
INTERRUPT.ENTRY  is  used  to  connect  an  interrupt  entry  directly  to  the 
required  interrupt  vector,  and  is  described  below. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  M1L-STD- 
1750A  Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 
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Tasks  with  interrupt  entries  but  no  pragma  LEVEL  run  at  interrupt  level 
0  only  while  accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of 
the  same  level  are  inhibited  while  in  the  handler.  When  not  accepting 
an  interrupt,  the  task  runs  with  all  interrupts  enabled.  It  is,  however, 
possible  to  lose  interrupts  with  this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  LEVEL  behaves  like  an 
ordinary  entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  LEVEL 
behaves  like  a  conditional  entry  call.  If  there  is  an  accept  statement 
waiting  for  the  interrupt,  the  body  of  the  accept  statement  is  executed 
immediately.  When  the  body  is  complete,  the  task  is  inserted  in  the 
ready  queue  and  the  interrupt  completed  by  a  retum-from-interrupt 
instruction.  The  accept  statement  can  call  subprograms  and  make  entry 
calls,  but  must  not  suspend  the  task  before  the  interrupt  is  dismissed, 
otherwise  the  program  repeatedly  services  the  interrupt  unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 

Normal  Ada  interrupt  entries  cause  a  tasking  reschedule  each  time  an 
interrupt  occurs.  This  inevitably  incurs  a  performance  overhead,  and 
may  mean  that  interrupts  are  not  serviced  quickly  enough.  In  order  to 
avoid  this  problem,  XD  Ada  supplies  pragma  DIRECT JNTERRUPT_ 
ENTRY,  which  causes  the  interrupt  entry  to  be  connected  directly  to 
the  required  interrupt  vector.  This  run-time  efficiency  greatly  improves 
response  limes.  The  form  of  this  pragma  is  as  follows: 

pra«M  DIR8CT_INTERRUPT_SNTRY( inter rupt_entry)  J 

Pragma  DIRECT JNTERRUPT_ENTRY  may  be  used  where  the  pro¬ 
gram  adheres  to  one  of  two  supported  code  models.  In  fact,  most 
applications  will  naturally  adhere  to  one  or  other  of  the  models,  so 
the  practical  restrictions  from  this  requirement  are  minimal.  The  use 
of  pragma  DIRECT_INTERRUPT_ ENTRY  must  meet  certain  semantic 
conditions.  These,  along  with  the  checks  carried  out  by  the  compiler 
and  run-time  system,  are  described  in  full  in  the  XD  Ada  MIL-STD-1750A 
Run-Time  Reference  Manual  part  of  this  manual. 

Note  that  it  is  essential  that  the  lowest  level  direct  interrupt  (or  interrupt 
procedure)  is  always  higher  than  the  highest  level  normal  interrupt,  in 
order  that  the  direct  interrupt  context  is  not  left  as  a  result  of  interruptive 
preemption. 
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The  models  and  the  related  conditions  are  described  in  full,  and  ex¬ 
amples  of  the  models  in  use  are  given,  in  the  XD  Ada  MIL-STD-1750A 
Run-Time  Reference  Manual  part  of  this  manual. 

Interrupt  procedures  and  Package  INTERRUPT.SUPPORT  are  also 
described  in  the  XD  Ada  M1L-STD-1750A  Run-Time  Reference  Manual  part 
of  this  manual. 
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In  addition  to  the  standard  predefined  pragmas,  described  in  Annex  B 
of  the  Reference  Manual  for  the  Ada  Programming  Language,  XD  Ada  sup¬ 
ports  pragmas  CALL.SEQUENCE.FUNCTION,  CALL.  SEQUENCE 
PROCEDURE,  UNK.OPTION,  and  TITLE,  which  are  defined  here. 
This  annex  also  summarizes  the  definitions  given  elsewhere  of  the 
remaining  implementation-defined  pragmas. 

Definitions 

CALL  SEQUENCE. FUNCTION 
CALL.SEQUENCE.PROCEDURE 

The  pragma  CALL_SEQUENCE_PROCEDURE  is  used  for  describing 
machine  code  insertions  or  exported  subprograms.  It  specifies  how 
parameters  are  mapped  onto  registers,  and  which  registers  must  be 
preserved,  for  machine  code  insertions  (see  Section  13.8).  The  pragma 
CALL.SEQUENCE.FUNCTION  is  also  provided.  These  pragmas  have 
the  form: 

pragma  CALL.SBQUBNCE.FUNCT I ON 

{[  [UNIT  ->]  internal.name 
(,  [RESULT.TYPE  »>]  type.mark  ] 

(,  (PARAMETER.TYPES  ->)  7  parameter.types  )  ] 

[,  [MECHANISM  »>)  mechanism  ] 

(,  [RESULT.MECHANISM  ->]  mechanism.spec  ] 

(,  [PRESERVED  REGISTERS  ■>  J  (  registers  )  ) 

); 

pragma  CALL_SEQUENCE_PROCEDURE 

([  [UNIT  »>)  internal.name 
[,  [ PARAMETER.TYPES  ->]  (  parameter.types  )  ] 

{,  [MECHANISM-*?)  mechanism  ] 

[,  [PRESERVED_REGISTERS  ->  )  (  registers  )  ] 

)? 
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parameter_types  1 1 » 

null  T  type_mark  (,  type_mark) 

mechanism  ti« 

mechanism_spec  |  (  mechaiiism_spec  {,  mechanism_spec}  ) 
mechanism_apec  tt» 

mechanism_name  [  (  (REGISTER  ->  J  regiater_nama  )  ) 

mechanism_name  t i» 

VALUE-  | 

REFERENCE  |  8IT_REFERENCE  | 

DOPE,' VECTOR  |  8IT~D0PE_VECT0R 

registers  i i - 

null  |  register_name  {,  rogiater_name  } 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 
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The  result  mechanism  option  is  used  only  for  functions;  it  specifies  the 
parameter-passing  mechanism  for  passing  the  result  type. 

Mechanism  names  are  described  in  Section  13. 9a.  1.1. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved;  in  this  case  the  effect  is  one  of 
the  following; 

•  If  the  body  of  the  subprogram  is  written  in  Ada,  the  compiler 
calculates  which  registers  are  preserved 

•  If  the  body  of  the  subprogram  is  a  machine  code  insertion,  the 
pragma  has  the  same  effect  as  pragma  IMPORT. PROCEDURE 


LINK..OPTION 

This  pragma  is  used  to  associate  link  option  hie  names  with  a  program. 
Link  option  files  are  used  to  specify  the  target  and  mapping  definitions 
to  be  used  when  building  the  program.  In  this  way,  they  do  not  have 
to  be  explicitly  defined  on  the  XDACS  LINK  command  line.  The 
appropriate  external  target  and  mapping  definitions  (in  the  form  of  link 
option  files)  are  entered  into  the  program  library  by  use  of  the  XDACS 
command  COPY  UNK.OPTION/FOREIGN,  as  described  in  Developing 
XD  Ada  Programs  o  •  'MS  Systems  for  the  MIL-STD-175QA.  If  a  suitable 
link  option  file  exists  in  another  program  library,  it  can  be  copied  to 
the  current  program  library  with  the  XDACS  command  COPY  LINK. 
OPTION.  The  advantage  of  using  link  option  files  is  that  the  program 
definition  is  separate  from  the  program  itself,  and  so  can  be  altered 
without  making  the  last  compile  obsolete.  The  UNK.OPTION  pragma 
therefore  removes  the  need  to  recompile  the  whole  program.  More 
detail  on  this  topic  can  be  found  in  Sections  7.9  and  8.10  of  Developing 
XD  Ada  Programs  on  VMS  Systems  for  the  MIL-STD-1750A. 

Pragma  UNK.OPTION  has  the  form: 

prtfM  LINK.OPTION  (link-option-f lie-name 
[ , link-option- file-name ] > ; 

link-option-f ila-name  »«■ 

[ TARGBT“> !  target-option 
|  [MAPPINQ->]  mapping-option 

This  pragma  is  only  allowed  in  the  outermost  declarative  part  of  a 
subprogram  that  is  a  library  unit;  at  most  one  such  pragma  is  allowed 
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in  a  subprogram.  If  it  occurs  in  a  subprogram  other  than  the  main 
program,  this  pragma  has  no  effect  (see  Sections  9.8  and  9.9  (LRM)). 


TITLE 

Takes  a  title  or  a  subtitle  string,  or  both,  in  either  order,  as  arguments. 

Pragma  TITLE  has  the  form: 

praga*  TITLE  (titling-option 
( , titling-option ) ) ; 

titling-option  t« 

(TITLE  «>]  atring_literal 
|  (SUBTITLE  ->]  strlng_literal 

This  pragma  is  allowed  anywhere  a  pragma  is  allowed;  the  given  strings 

supersede  the  default  title  or  subtitle  portions  of  a  compilation  listing. 

Summary 

Pragma  Meaning 

EXPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  The  pragma  permits 
an  Ada  exception  to  be  handled  by 
programs  written  in  XD  Ada  MIL-STD- 
1750A  assembly  language  (see  Section 
13.9a.3.2). 

EXPORT_ FUNCTION  Takes  an  internal  name  denoting  a 

function,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  parameter 
types,  and  result  type  as  arguments. 

This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  a  function  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  In 
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EXPORT.OBJECT 


EXPORT.PROCEDURE 


the  case  of  a  function  declared  as  a 
compilation  unit,  the  pragma  is  only 
allowed  after  the  function  declaration 
and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming  dec¬ 
laration,  and  is  not  allowed  for  a  generic 
function  (it  can  be  given  for  a  generic 
instantiation).  This  pragma  permits  an 
Ada  function  to  be  called  from  a  pro¬ 
gram  written  in  assembly  language  (see 
Section  13.9a.l.2). 

Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  exter¬ 
nal  designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  size  des¬ 
ignator  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item  at  the  outermost  level  of  a  library 
package  specification  or  body,  and  must 
apply  to  a  variable  declared  by  an  earlier 
declarative  item  of  the  same  package 
specification  or  body;  the  variable  must 
be  of  a  type  or  subtype  that  has  a  con¬ 
stant  size  at  compile  time.  This  pragma 
is  not  allowed  for  objects  declared  with  a 
renaming  declaration,  and  is  not  allowed 
in  a  generic  unit.  This  pragma  permits 
an  Ada  object  to  be  referred  to  by  a 
routine  written  in  assembly  language  (see 
Section  13.9a.2.2). 

Takes  an  internal  name  denoting  a  pro¬ 
cedure,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  parameter 
types  as  arguments,  litis  pragma  is  only 
allowed  at  the  place  of  a  declarative  item, 
and  must  apply  to  a  procedure  declared 
by  an  earlier  declarative  item  of  the  same 
declarative  part  or  package  specification. 
In  the  case  of  a  procedure  declared  as 
a  compilation  unit,  the  pragma  is  only 
allowed  after  the  procedure  declaration 
and  before  any  subsequent  compilation 
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unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
generic  procedure  (it  may  be  given  for 
a  generic  instantiation).  This  pragma 
permits  an  Ada  routine  to  be  called  from 
a  program  written  in  assembly  language 
(see  Section  H.9a.l.2). 

IMPORT-EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  The  pragma  is  included  for 
compatibility  with  VAX  Ada  (see  Section 
13.9a.3.1). 

IMPORT. FUNCTION  Takes  an  internal  name  denoting  a  func¬ 

tion,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  parameter  types, 
and  result  type  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Se<  don  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declar¬ 
ative  item,  and  must  apply  to  a  function 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  ane  <.  <»  hunc- 
tion  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  function 
declaration  and  before  any  subsequent 
compilation  unit.  This  pragma  is  allowed 
for  a  function  declared  with  a  renaming 
declaration;  it  is  not  allowed  for  a  generic 
function  or  a  generic  function  instantia¬ 
tion.  This  pragma  permits  an  assembly 
language  routine  to  be  used  as  an  Ada 
function  (see  Section  13.9a.l.l). 
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IMPORT.OBJECT 


IMPORT.PROCEDURE 


Takes  an  internal  name  denoting  at>. 
object,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  as  arguments. 
This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item  at  the  outermost 
level  of  a  library  package  specification 
or  body,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item  of 
the  same  package  specification  or  body; 
tlw  variable  must  be  of  a  type  or  subtype 
that  has  a  constant  size  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit.  This 
pragma  permits  storage  declared  in  an 
assembly  language  routine  to  be  referred 
to  by  an  Ada  program  (see  Section 
13.9a.2.1). 

Takes  an  internal  name  denoting  a 
procedure,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  pa¬ 
rameter  types  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declara¬ 
tive  item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  declaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure  de¬ 
clared  with  a  renaming  declaration;  it  is 
not  allowed  for  a  generic  procedure  or 
a  generic  procedure  instantiation.  This 
pragma  permits  an  assembly  language 
routine  to  be  used  as  an  Ada  procedure 
(see  Section  13.9a.l.l). 
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INTERFACE 

LEVEL 

STORAGE.UNIT 

SUPPRESS.ALL 

VOLATILE 


In  XD  Ada,  pragma  INTERFACE  is 
required  in  combination  with  pragmas 
IMPORT.FUNCTION  and  IMPORT, 
PROCEDURE  (see  Section  13.9a.l). 

This  pragma  identifies  a  task  or  task  type 
as  running  at  interrupt  level.  Pragma 
LEVEL  has  one  argument  specifying 
the  level  for  its  interrupts  (see  Section 
13.5.1). 

In  XD  Ada,  the  only  argument  allowed 
for  this  pragma  is  16. 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that  all  run¬ 
time  checks  in  the  unit  are  suppressed 
(see  Section  11.7). 

Takes  the  simple  name  of  a  variable 
as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declaration  and  the  pragma  must  both 
occur  (in  this  order)  immediately  within 
the  same  declarative  part  or  package 
specification.  The  pragma  must  appear 
before  any  occurrence  of  the  name  of 
the  variable  other  than  in  an  address 
clause  or  in  one  of  the  XD  Ada  pragmas 
IMPORT_OBJECT  or  EXPORT.OBJECT. 
The  variable  cannot  be  declared  by  a 
renaming  declaration.  The  VOLATILE 
pragma  specifies  that  the  variable  may  be 
modified  asynchronously.  This  pragma 
instructs  the  compiler  to  obtain  the  value 
of  a  variable  from  memory  each  time  it 
is  used  (see  Section  9.11). 
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This  chapter  supplies  details  of  three  pragmas  introduced  by  XD  Ada 
MIL-STD-1750A  Version  1.2,  pragma  DIRECT_INTERRUPT_ ENTRY, 
pragma  IDENT  and  pragma  TIME.SLICE.  XD  Ada  pragmas  in  ad¬ 
dition  to  those  defined  in  Annex  B  of  the  Reference  Manual  for  the 
AdaProgramming  Language  (CALL.SEQUENCE.  FUNCTION,  CALL. 
SEQUENCE.PROCEDURE,  LEVEL,  LINK.OPTION  and  TITLE)  are 
described  in  the  XD  Ada  MIL-STD-1750A  Supplement  to  the  Ada  Language 
Reference  Manual  for  Version  1.0. 

Definitions 

IDENT 

Takes  a  string  literal  of  31  or  fewer  characters  as  the  single  argument. 
The  pragma  IDENT  has  the  following  form: 

pragma  IDENT  ( atring_literal ) ; 

This  pragma  is  allowed  only  in  the  outermost  declarative  part  of  a 
compilation  unit.  The  given  string  is  used  to  identify  the  object  module 
associated  with  the  compilation  unit  in  which  the  pragma  IDENT  occurs. 

Summary 

Pragma  Meaning 

DIRECT_INTERRUPT_ENTRY  Takes  the  simple  name  of  an  interrupt 

entry,  which  must  have  no  parameters, 
as  the  single  argument.  This  pragma 
signals  to  the  compiler  that  the  interrupt 
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entry  is  to  be  directly  connected  to  the 
hardware  interrupt  (see  Section  13.5.1). 

TIME_SUCE  Takes  a  static  expression  of  the  prede¬ 

fined  fixed  point  type  DURATION  (in 
Package  STANDARD)  as  the  single  ar¬ 
gument.  This  pragma  is  only  allowed 
in  the  outermost  declarative  part  of  a 
library  subprogram,  and  at  most  one 
such  pragma  is  allowed  in  a  library  sub¬ 
program.  It  has  an  effect  only  when 
the  subprogram  to  which  it  applies  is 
used  as  a  main  program.  This  pragma 
specifies  the  nominal  amount  of  elapsed 
time  permitted  for  the  execution  of  a  task 
when  other  tasks  of  the  same  priority  are 
also  eligible  for  execution.  A  positive, 
nonzero  value  of  the  static  expression 
enables  scheduling  for  all  tasks  in  the 
subprogram;  a  negative  or  zero  value 
disables  it  (see  Section  9.8a). 
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